How DWARF Works | Hacker News Reader

How DWARF Works

calabro.io

32 pointsjcalabro13 comments

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.

Great catch! I wrote these quickly for a 1-week code jam, and it slipped through. Thanks, I've adjusted the post! :)

> 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.

I agree with this whole thread. I do use VS Code as my debugger frontend for C++ on Linux, but it's a real bummer compared to what's available on Windows. Hence this series!

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?

I don't think so since you could do a front end over DAP, right? No linking required therefore. IANAL

It was added well after GDB's design was set. Only when LLVM brought a permissively licensed competitor did the FSF start opening up its toolchain to not be left out in the race to the bottom.

Totally shameless plug: if you like rr's technical capabilities but not it's UI, you might love Pernosco (https://pernos.co/)

I have poked around with Pernosco, and it's very impressive! I just added a paragraph to the intro of this series about it. Pernosco is so cool!

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!

Reply on news.ycombinator.com