Re: -fno-omit-frame-pointer does not work as advertised

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> What about the new SFrame unwind info?

We're closely following up on this new format and will compare it against frame pointers if a patch introducing a kernel unwinder for sframe is proposed and likely to be merged. It's still very early days for SFrame though so we'll have to see what happens first.

Cheers,

Daan

________________________________________
From: Demi Marie Obenour <demiobenour@xxxxxxxxx>
Sent: 16 January 2023 20:33
To: devel@xxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: -fno-omit-frame-pointer does not work as advertised

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

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@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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux