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
