One nit to pick
> It's a bit tough to tell because we're only one function call deep, but this data is stored in a tree.
The call graph doesn't actually appear (with one exception, see below) in the DWARF. DWARF is a tree of the program constructs as they appear in the source. Local variables are children of the function they appear in. Member variables are children of the class they appear in. Global variables are children of the namespace or compilation unit they appear in. Functions are children of the namespace, class, or compilation unit they appear in, etc.
The exception to this is inlined functions. Inlines are represented with two pieces. DWARF for the function is emitted in the place where it appears in the source describing things that are shared across every instance of the function, like its return type, names of its parameters and local variables, etc. Then at each inlined site, a special inline entry is emitted. This special inline entry contains a reference pointing to the shared part of the DWARF, and all the information that is specific to a particular instance of the inlined function, such as which register variable X is located in.
> We have gdb, lldb, and rr (plus about a million graphical front ends, none of which are good).
Strongly agree - I've spent a great deal of time trying to find a good GUI for gdb, but it's all so janky compared to proper IDE debugging. As a result I only break out gdb as a last resort where printf statements don't do the job.
VSCode is 'quite ok' on Linux as gdb frontend. The main limitation is the really bare bones variable view panel. With the MS C/C++ and CMake Tools extensions debugging pretty much works out of the box and feels 'IDE like' (in that you can select the build and debug targets instead of writing a launch.json and tasks.json file, and starting into the debugger for the current debug target is just pressing F5).
The other debugger frontend that works quite ok is QtCreator.
Very mid compared to Visual Studio in my experience. You don't even get a modules window, and there's a whole litany of core C++ debugging features missing.
Yeah, but compared to the Visual Studio debugger, pretty much everything is stuck in the stone age unfortunately.
Totally shameless plug: if you like rr's technical capabilities but not it's UI, you might love Pernosco (https://pernos.co/)
IIRC the FSF does this on purpose to ensure anything based on GDB must be linked with it and therefore GPL covered.
Is GPL really an impediment for someone developing a GDB frontend?