* Neal Gompa: > So my semi-naive interpretation of the problem here is that glibc is > special in that it doesn't provide any support for real-time tracing > or profiling. I'm not sure that justifies removing this flag globally, > as there are plenty of middleware stacks that do their own thing or > even things that don't use glibc string functions at all.
Sorry, I tried to make clear that this is regular C code compiled with the -mno-omit-leaf-frame-pointer flag, like the rest of the distribution. The only way in which glibc is special is that Wilco Dijkstra from Arm has recently optimized malloc to make the happy paths as fast as possible, intentionally triggering the shrink-wrapping optimization through careful use of tail-calls to no-inline functions. Any other packages can do the same, either manually or even automatically in some cases, with profile-guided optimization. I think even before these malloc changes, typical workloads had like 10% of their profiling samples in code regions where the frame pointer was not yet set up. And dropping -mno-omit-leaf-frame-pointer might not even increase that percentage because short functions without memory accesses are more likely to drop from profiles altogether. Thanks, Florian -- _______________________________________________ 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
