3 ms·
> it only begs the question of whether the issue is perf or DWARF AFAIK there are two issues at play here. 1. There's a bug in the Linux kernel where it somet
by kouteiheika 4y ago
> it only begs the question of whether the issue is perf or DWARF
AFAIK there are two issues at play here.
1. There's a bug in the Linux kernel where it sometimes return an invalid RBP register through `perf_event_open`.
2. The compiler doesn't generate the necessary DWARF info to support unwinding asynchronously, so depending on where exactly you land in a function you might not be able to unwind the stack. (This is why unwinding from *within* the program always works correctly but unwinding from *outside* the program with perf doesn't.)
Source: I wrote my own sampling profiler.
- ShroudedNight 4y agoI would be interested in taking / motivating a deeper dive into the failure modes of -fasychronous-unwind-tables, would you happen to recall a scenario where the undwinding problems you discuss reproduce ~consistentlyish?
- AshamedCaptain 4y agoasynchronous-unwind-tables is not the default. Ever since I enabled it, I have never seen gdb fail to unwind.
- kouteiheika 4y agoIt was quite a long time ago, so unfortunately at this point I don't remember what exact problems I encountered with `-fasychronous-unwind-tables`. (I think it might have been completely broken and did nothing on 32-bit ARM? But I might be misremembering.) And there's of course the issue that you'd need everything to be compiled with it (because the program you're profiling is going to call into external dynamically linked libraries), which on an average system you most likely won't have.