On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland 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-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...

On 17/07/2020 22:02, Mathias Gaunard wrote:

On Fri, 17 Jul 2020 at 15:20, Niall Douglas via Boost 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