Re: [outcome] Inline GDB pretty printing support

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-07-01 15:00:40

On 01/07/2024 15:48, Vinnie Falco wrote:
> On Mon, Jul 1, 2024 at 7:45 AM Niall Douglas via Boost 
> <boost_at_[hidden] <mailto:boost_at_[hidden]>> 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_005fscripts-section.html. 
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