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).
> I don't work at Facebook and I have no idea how Facebook do things, but I
> _very strongly doubt_ that they are disabling all those optimizations in
> their binaries for the sake of perfect unwinding behavior, and yet despite
> this they claim to have realized a lot of value from this change. If you
> want to claim that this is "useless", then you are also claiming that any
> benefit which has already been realized by using it is retroactively
> invalid.
As I understand it, Facebook does not even use -mno-omit-leaf-frame-pointer,
so their profiles will never include the callers of leaf functions, even
those that do set up a stack frame.
Kevin Kofler
_______________________________________________
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
