On 1/15/23 12:58, Kevin Kofler via devel wrote: > Daniel Alley wrote: >> The quotation says the opposite of what you are saying. "leaves the frame >> pointer pointing to the caller's frame" => the caller set the frame >> pointer, the leaf did not, therefore the leaf function will not show up >> but the caller still will. > > No, that is not what it says. You are missing an important point there. To > understand that point, you need to look more closely at how unwinding works, > so let me (as a cross-toolchain developer) explain it to you: > > The first thing the sampling profiler will see is the current instruction > pointer / program counter. That is the very instruction the CPU is currently > executing (or, depending on the CPU, it may actually be the next instruction > that will be executed). So it always points to the function currently being > executed. I.e., that function will ALWAYS show up in the backtrace, even if > unwinding is completely broken. > > But then you want to locate the caller. To locate the caller, you need to > find the return address of the current function (i.e., where the `ret` > instruction terminating the function will return to) on the stack. For that, > the frame-pointer-based unwinder will use the frame pointer. But the frame > pointer still points to the caller's stack. So what it will see is the > CALLER's return address, i.e., the caller's caller! The caller itself, on > the other hand, will be missing. > >> You seem to be arguing that because the solution is not 100% perfect (and >> it was already acknowledged that it is not), it is useless. > > It is at least not as useful as the change proponents claim and clearly not > worth the performance loss that will be imposed on all users. > >> Is shipping debug symbols for an optimized binary completely useless just >> because there are situations where optimizations like inlining and TCO >> make the executed code radically different from the source code, and >> therefore make it impossible to trace the execution line by line? > > Debugging information has improved over the years so that optimized > executables can actually be debugged in a better and better way over time. > E.g., GDB can actually synthesize the value of some variables that have been > optimized out, but can be computed from values actually present in registers > or stack variables. Of course, if the variable was optimized out completely, > it is impossible to view its value, but within this kind of limitations, > debugging optimized executables actually works pretty well these days. > > Part of that work was on unwinding, which is why frame pointers are actually > unnecessary to perform unwinding if the unwinder works properly, making them > an obsolete pessimization. The only reason we are having this discussion is > because there are some broken tools that still do not understand unwinding > information in 2023, putting them one or two decades behind the state of the > art (and the Linux kernel developers' stubborn refusal to allow a DWARF > unwinder into the kernel is one of the reasons for that and should be > addressed by a downstream kernel patch, not by pessimizing the entire > distribution). Would you be willing to write such a patch and send a PR to include it in Fedora’s kernel packages? -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
