Re: [boost] [outcome] Inline GDB pretty printing support

On 01/07/2024 15:48, Vinnie Falco wrote:

On Mon, Jul 1, 2024 at 7:45 AM Niall Douglas via Boost mailto:boost@lists.boost.org> wrote:

inline GDB pretty printing support, whereby we embed into all binaries using Outcome the Python script to display the state of `result<>/outcome<>`.

Huh...I don't quite understand what this means. Although from the source file it looks like you are embedding Python code in the library? Can you please explain this a little better, or provide some links to reading materials where this is explained? Visualizer support is an ongoing area of interest for my libraries.

Sure! As you already know, you can write a Python helper which GDB loads to better render types in GDB. This is a great facility. Most docs online say you have to manually patch in visualisers to your `.gdbinit`, and indeed that is one technique and that works well. It is kinda bothersome though, and tedious and it's easy to forget you've done it and then the code gets changed and the visualiser doesn't and then it gets annoying. A less well known technique I've had in the Outcome todo list since I first wrote Outcome is you can embed the Python script inside a magical ELF section which causes it to appear in all binaries which include your library. This magical ELF section will be autoloaded by GDB if your `.gdbinit` has whitelisted the paths where your binaries are. If you haven't whitelisted it, you get a useful diagnostic from GDB hinting you should enable the whitelist. You can of course whitelist all paths in your `.gdbinit`, and then all auto loaded inline GDB visualisers "just work". This is very convenient. In terms of public docs about this, there is a terse section in the GDB docs at https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005f.... What had blocked me until now was the appropriate asm incantation to get the sections to auto merge in a header only library and for it to "just work". I finally created the time to get this working right a few weeks ago out of frustration with working with Outcome in GDB, and I'm very glad it's done. My current day job has me mainly working on a C codebase. Many don't realise Outcome has a C interface, due to C being C it is highly type erased so having a GDB visualiser which prints the contents of the state is very very useful in my current day job right now. Feel free to lift ideas from my linked file into your code. I agree more inline embedded visualisers in Boost would be a great help. Niall