Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

It doesn't give any insight as to why, though, which makes it very weak evidence toward whether DWARF is the real problem.

View on HN

It's not so much DWARF is the problem as it is that the information is just lost in omit-framepointer mode. You can't reconstruct it from nothing.

There's a related problem of compilers generating imperfect debuginfo that fails to reconstruct local variables from registers/memory due to an incomplete DWARF representation, but I don't think that plays a roll in unwinding. (But maybe something similar does.)

What information is lost? The call stack can't be lost or you'd crash immediately.

It's lost in the translation to DWARF. Of course the program knows how to unwind its own stack correctly, but explaining how to do this for arbitrary programs is untenable without DWARF to help, and it's annoying to parse and compilers don't emit it correctly.

If the information is lost by DWARF then I'd say that DWARF is clearly the problem.

Unless DWARF can handle it fine and compilers are thoroughly broken, in which case it's a tossup between "DWARF is fundamentally flawed" and "compiler designers are lazy for some unknown reason"?

DWARF can handle it fine, it’s that compilers don’t generate correct information or the tools to parse DWARF don’t do it properly.

The problem is that with perf the stack trace is collected by the kernel (when the interrupt from the performance counters fires), and the kernel doesn’t implement dwarf unwinding of user space code.

It _could_, but the kernel folks have made it pretty clear they don’t want to put any code related to dwarf in the kernel.

There are tools which do dwarf unwinding with eBPF but I have not used them myself.

Reply on news.ycombinator.com