[Core] gdb/VS Pretty-printers for Boost

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
There's been a number of independent efforts to produce pretty-printers (or
"visualizers") for different popular Boost libraries. The one I like most
due to its thoughtful execution is probably this one
<https://github.com/ruediger/Boost-Pretty-Printer>. But maintaining a set
of pretty-printers out of tree is a challenge for all the usual reasons.
Having libraries optionally supply and maintain them is much more
sustainable.

Would it be possible to define a small set of standard ways (file
locations, build steps) for a library to store and install pretty-printers
for gdb and/or Visual Studio?

Thanks,
Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
Maybe we could encourage the author to bring it to us as a 'tool' -- I
don't know that we need a review for that even.  Regardless, I wasn't aware
of these -- cool!

On Wed, Jul 15, 2020 at 9:36 AM Jeff Trull via Boost <[hidden email]>
wrote:

> There's been a number of independent efforts to produce pretty-printers (or
> "visualizers") for different popular Boost libraries. The one I like most
> due to its thoughtful execution is probably this one
> <https://github.com/ruediger/Boost-Pretty-Printer>. But maintaining a set
> of pretty-printers out of tree is a challenge for all the usual reasons.
> Having libraries optionally supply and maintain them is much more
> sustainable.
>
> Would it be possible to define a small set of standard ways (file
> locations, build steps) for a library to store and install pretty-printers
> for gdb and/or Visual Studio?
>
> Thanks,
> Jeff
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/07/2020 17:35, Jeff Trull via Boost wrote:

> There's been a number of independent efforts to produce pretty-printers (or
> "visualizers") for different popular Boost libraries. The one I like most
> due to its thoughtful execution is probably this one
> <https://github.com/ruediger/Boost-Pretty-Printer>. But maintaining a set
> of pretty-printers out of tree is a challenge for all the usual reasons.
> Having libraries optionally supply and maintain them is much more
> sustainable.
>
> Would it be possible to define a small set of standard ways (file
> locations, build steps) for a library to store and install pretty-printers
> for gdb and/or Visual Studio?

Standlone Outcome links in via cmake target the debugger pretty printer
for MSVC. It silently "just works".

I am unaware of any similar "silently just works" technique for gdb,
sadly. And you might note that on my Linux at least, libstdc++ has no
default discovered pretty printers for gdb either.

Anyway, any library maintainer I'm sure would accept a PR adding a MSVC
pretty printer for their library.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Em qua., 15 de jul. de 2020 às 13:36, Jeff Trull via Boost <
[hidden email]> escreveu:

> There's been a number of independent efforts to produce pretty-printers (or
> "visualizers") for different popular Boost libraries. The one I like most
> due to its thoughtful execution is probably this one
> <https://github.com/ruediger/Boost-Pretty-Printer>.


Another interesting Boost "pretty printer" is <
https://github.com/lenerd/fiber-gdb> by Lennart Braun.

This one is interesting because parts of this printer could be imported by
other pretty printers. And the imported part is architecture-specific and
might break among the Boost.Context releases, so it does make some sense to
have this piece lying around the repo itself.


--
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland <[hidden email]> wrote:

> Maybe we could encourage the author to bring it to us as a 'tool' -- I
> don't know that we need a review for that even.  Regardless, I wasn't aware
> of these -- cool!
>
>>
>>
What concerns me about this approach is that the pretty-printers will
quickly drift out of sync with the libraries themselves. In fact it has
already happened - if you look at Rüdiger's repo you can see he had to
incorporate a versioning scheme, as well as unit tests, to ensure the code
stayed correct (one of the features I really like about his work). Some
method where individual libraries produced visualizers that were combined
at install time would be ideal, as they would be owned by each maintainer.

I think a good starting point would simply be to say "if you want to supply
pretty-printers, please put them in XX directory in your library and use
the following conventions". The work of producing a single resource for all
of Boost could wait until a few libraries had started maintaining these.

Off the top of my head, how about lib/XXX/debug/gdb/pp, where pp becomes
the Python module, analogous to what on my system is
/usr/share/gcc-10/python/libstdcxx/v6/,
the top level libstdc++ pretty-printer? Similar work could be done, if
desired, for VSCode and lldb, in parallel directories.

Best,
Jeff T.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
On 2020-07-17 21:48, Jeff Trull via Boost wrote:

> On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland <[hidden email]> wrote:
>
>> Maybe we could encourage the author to bring it to us as a 'tool' -- I
>> don't know that we need a review for that even.  Regardless, I wasn't aware
>> of these -- cool!
>>
>>>
>>>
> What concerns me about this approach is that the pretty-printers will
> quickly drift out of sync with the libraries themselves. In fact it has
> already happened - if you look at Rüdiger's repo you can see he had to
> incorporate a versioning scheme, as well as unit tests, to ensure the code
> stayed correct (one of the features I really like about his work). Some
> method where individual libraries produced visualizers that were combined
> at install time would be ideal, as they would be owned by each maintainer.

I can tell that putting the responsibility of keeping the pretty
printers actual on the library maintainer will not necessarily improve
the situation. Especially not if the library maintainer is not familiar
with the pretty printers know-how.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 17 Jul 2020 at 15:20, Niall Douglas via Boost
<[hidden email]> wrote:

> I am unaware of any similar "silently just works" technique for gdb,
> sadly. And you might note that on my Linux at least, libstdc++ has no
> default discovered pretty printers for gdb either.

Of course there are silently-just-works approaches for gdb.
You just have to create a section called .debug_gdb_scripts (you can
have any number of them)., and gdb will run its content as a Python
script when it loads the binary.

In practice though, people only use this to specify how to load
scripts that are elsewhere on the filesystem, rather than embedding
all the scripts in the object file itself. But I suppose both modes of
operation are valid.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
On 2020-07-18 00:02, Mathias Gaunard via Boost wrote:
>
> Of course there are silently-just-works approaches for gdb.
> You just have to create a section called .debug_gdb_scripts (you can
> have any number of them)., and gdb will run its content as a Python
> script when it loads the binary.

I wonder if this can have security implications...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
gdb has security implications -- it's not going to be deployed on a
production VM for anyone that's serious about security.

On Fri, Jul 17, 2020 at 3:12 PM Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-07-18 00:02, Mathias Gaunard via Boost wrote:
> >
> > Of course there are silently-just-works approaches for gdb.
> > You just have to create a section called .debug_gdb_scripts (you can
> > have any number of them)., and gdb will run its content as a Python
> > script when it loads the binary.
>
> I wonder if this can have security implications...
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Core] gdb/VS Pretty-printers for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 17/07/2020 22:02, Mathias Gaunard wrote:

> On Fri, 17 Jul 2020 at 15:20, Niall Douglas via Boost
> <[hidden email]> wrote:
>
>> I am unaware of any similar "silently just works" technique for gdb,
>> sadly. And you might note that on my Linux at least, libstdc++ has no
>> default discovered pretty printers for gdb either.
>
> Of course there are silently-just-works approaches for gdb.
> You just have to create a section called .debug_gdb_scripts (you can
> have any number of them)., and gdb will run its content as a Python
> script when it loads the binary.
>
> In practice though, people only use this to specify how to load
> scripts that are elsewhere on the filesystem, rather than embedding
> all the scripts in the object file itself. But I suppose both modes of
> operation are valid.

The above was very useful, thank you Mathias. I had thought that you
could only embed paths to python scripts to load, and those always fall
foul of gdb's path whitelisting, so it's useless to me.

But the apparent ability to embed arbitrary python scripts, well that's
new to me and far more useful looking. I've raised an issue with links
to relevant info at:

https://github.com/ned14/outcome/issues/233

Many thanks for the tip!

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost