[Core] gdb/VS Pretty-printers for Boost
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
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 <boost@lists.boost.org> 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
On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland <azswdude@gmail.com> 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.
On 2020-07-17 21:48, Jeff Trull via Boost wrote:
On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland <azswdude@gmail.com> 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.
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
On Fri, 17 Jul 2020 at 15:20, Niall Douglas via Boost <boost@lists.boost.org> 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.
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...
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 < boost@lists.boost.org> 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
On 17/07/2020 22:02, Mathias Gaunard wrote:
On Fri, 17 Jul 2020 at 15:20, Niall Douglas via Boost <boost@lists.boost.org> 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
On Fri, 17 Jul 2020 at 15:20, Niall Douglas via Boost <boost@lists.boost.org> 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.
Then your distro is doing it wrong.
Em qua., 15 de jul. de 2020 às 13:36, Jeff Trull via Boost < boost@lists.boost.org> 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/
participants (7)
-
Andrey Semashev -
Jeff Garland -
Jeff Trull -
Jonathan Wakely -
Mathias Gaunard -
Niall Douglas -
Vinícius dos Santos Oliveira