https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Lukas Grätz from comment #29) > Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I > trusted comment #10 here, as it made sense. See PR114116. > glibc's backtrace() function and friends only reports function names and > addresses. This looks like the gdb bt command. I admit, I did not take a > proper look into that before. Yes, it is gdb bt. And it is what people heavily rely on for debugging, if something fails an assertion or aborts etc., they want to figure out why. > I belief this could and should be somehow be fixed by adding DWARF info that > certain callee-saved registers (= the function parameter values) were > overwritten. The corrected backtrace could look something like this: That can be arranged by emitting those .cfi_undefined directives... > #2 0x00000000004011d2 in baz (a=42, b=43, c=44, d=<optimised out>, > e=<optimised out>, f=<optimised out>, g=48, h=49) at /tmp/1.c:38 ... but really will not help users to debug/fix their code. > > So, I think we should limit this to -fno-unwind-tables or maybe > > -mcmodel=kernel. > Now I am confused. The optimization is limited to -fexceptions. And the > documentation of -funwind-tables says "Similar to -fexceptions, except". So > shouldn't -funwind-tables behave similar to -fexceptions? I don't see > anything kernel-specific here. Given that even with -fno-asynchronous-unwind-tables (or -fno-unwind-tables) gcc emits the unwind info, just not into .eh_frame but .debug_frame, we shouldn't disable it just when not emitting .eh_frame, but should just disable it always. There is a reason why it has been rejected years ago. If anything, guard it with some non-default -m* option and explain the consequences to users if they use it. Still, the guarding IMHO should be done on top of the PR114116 change, because having random crashes from backtrace or gdb bt even when user asked for it is a bad idea.
