by khuey on 9/29/2024, 1:07:14 PM
by jonathrg on 9/29/2024, 12:58:10 PM
> 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.
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.