On 1/16/23 08:40, Florian Weimer wrote:
> * Daniel Alley:
>
>> What has happened is that because -O2 optimized away all of the stack
>> access for the function, so it uses no space on the stack, so there is
>> no stack frame separate from the caller's.
>>
>> It is unlikely that the critical bottleneck of any applications will
>> be on such a function.
>
> Is it? Plenty of math functions and cryptographic primitives are like
> that. Anything that makes an inline system call, too. Maybe you can
> infer from the caller's caller where the time is spent in these cases.
> People certainly seem to be concerned about this gap because they
> included -mno-omit-leaf-frame-pointer in the build flags.
>
> This is something that an upstream/ABI discussion could cover, with some
> sort of protocol that ensures the toolchain produces something the
> intended tools can consume. For example, there could be a rule that
> only frames up to a certain size may lack a frame pointer, so that a
> fixed-size copy from the top of the stack can recover the caller address
> by looking at the DWARF unwinding data (out of context, for that frame
> alone). Or it could be spelt out that LBR has to be used to recover the
> calling frame. This isn't really something that Fedora can implement in
> a downstream change, though.
What about the new SFrame unwind info?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
