> If we can get SHSTK to work, the value of the DWARF integration and > performance work will diminish fairly quickly because most developers > will soon have CPUs with fairly deep (32 entry) LBR buffers, SHSTK > support, or both. This seems like a fairly bold assumption. I also want to add that as discussed in the proposal, we want to enable profiling not just on our laptops, but across our entire fleet that's running various generations of hardware. We can't simply replace all of our hardware just to get shadow stack support unfortunately. So we can't rely on new hardware features to get stacktraces. Of course, if shadow stack support lands upstream, is found to be reliable and is fully supported by all hardware running on our fleet, we'd definitely look into using it instead of frame pointers. But's it's going to take many years before we can rely by all our hardware. Aside from our use case, I don't think developers are constantly replacing their hardware either. I'd guess that with this approach we'd have many years of developers debugging why they're not getting full stacktraces only to find out their hardware doesn't support shadow stacks. So to summarize, while we're anxiously awaiting for one of the mentioned alternatives to become viable, at the moment we think all of them result in a degraded profiling experience compared to frame pointers, either due to being slow, being a prototype and not available upstream, or due to requiring new hardware support. Cheers, Daan ________________________________________ From: Florian Weimer <fweimer@xxxxxxxxxx> Sent: 11 July 2022 07:12 To: Matthias Clasen Cc: Development discussions related to Fedora Subject: Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal) * Matthias Clasen: > On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > >> If the GNOME's sysprof does not work with Fedora, fix it or use >> something else. Do not change how Fedora is built. > > The result of that attitude is that performance work in the desktop > space is happening on GNOME OS images, or in Flatpak runtimes instead > of on Fedora. Which is a bit sad for Fedora as a supposedly > developer-friendly environment. My comment was specifically about sysprof. I've been told that the GNOME developers will not even consider anything else. This means that we need to fix sysprof. If we do that, it will be possible to use GNOME OS for profiling on older CPUs, and hardware-assisted backtraces on newer CPUs on Fedora (at least Skylake and Zen 3, especially once we've got userspace SHSTK support). Even if this proposal is not accepted, I think we can collaborate on a couple of things: * Enhance sysprof with LBR and SHSTK support. * Enable userspace backtrace generation from BPF without frame pointers (possibly by using LBR and SHSTK at first). * Investigate use of the Systemtap and elfutils unwinders in these tools. * Speed up decoding of DWARF data structures using the BMI instruction sets (which only operate on scalar registers and should therefore be usable even within the kernel). According to <https://lore.kernel.org/all/c54327dc-75c9-db48-f7c1-59f9fcfca26f@xxxxxxx/> that's a major source of DWARF processing overhead, and I don't think it has to be. I'll try to get confirmation that it is technically feasible in priciple to use SHSTK to get arbitrarily deep backtraces from kernel space for userspace applications. If we can get SHSTK to work, the value of the DWARF integration and performance work will diminish fairly quickly because most developers will soon have CPUs with fairly deep (32 entry) LBR buffers, SHSTK support, or both. Thanks, Florian _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
