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.
The other debugger frontend that works quite ok is QtCreator.
However, I think it's aiming to solve different bugs than I am usually after. I want a very quick-to-use debugger because I like to step through all my code as I'm writing it to sanity check. It generally just helps me stay focused and make fewer errors (I'm not the most detail-oriented person in the world, and the debugger helps keep me on the rails).
Pernosco/rr are invaluable tools for solving much tougher bugs, but I want a better debugger for the "every-day" sort of stuff as well. Thank you for pushing the state of the art though, Pernosco is jaw-dropping!
> 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.
