Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

added 1 commit

4e1c9be2 - Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

added 1 commit

86d09431 - Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Hey, thanks for raising this topic! In case it wasn't clear to the reader, large portions of this text appear to have been lifted directly from the Fedora proposal (obviously fine since @daandemeyer likely wrote the Fedora proposal too ). Ideally, an Arch-specific take on the matter would be nice here IMHO.

TL;DR : Results in marginally slower code for the benefit of system profiling.

If Arch wants to "Keep up with the Joneses" (Fedora, Ubuntu, etc) then I suppose we want this. After all, in the past we have "borrowed" similar ideas from other distros for toolchain hardening/optimization etc. It probably boils down to consensus around "How important is system profiling to Arch?"

Edit: An interesting blog post on the topic: https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwarf-my-verdict/

For clarity: I did indeed write the Fedora change proposal as well so I'm just plagiarizing myself.

I think in this regard Fedora and Arch Linux are somewhat similar. Both are distributions that pull in the latest releases of packages before other distributions and thus benefit from both users and developers being able to do effective system profiling.

added 1 commit

deb02682 - Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Compare with previous version

added 1 commit

81b254f9 - Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Compare with previous version

Rendered: https://gitlab.archlinux.org/daandemeyer/rfcs/-/blob/fp/rfcs/0026-fno-omit-frame-pointer.rst

(Might want to put this into the MR description.)

Given the linked benchmarks showing a limited impact to performance in core libraries, and the benefit of this change for debugging and profiling, I'll approve this change. We may want to add a PKGBUILD option to omit frame pointers, however, in case we find sizable performance regressions in padticular packages.

approved this merge request

I had looked at whether to propose this in the past and landed on not proposing it in Arch for several reasons.

Performance:

the pyperformance benchmarks are concerning
SUSE engineers said between 5-10% performance hit
Phoronix found some very concerning performance hits (geometric mean of 14%, with all the associated caveats of that site...)

The acceptance in Fedora was not straight forward. The Fedora Engineering and Steering Committee rejected this proposal, and the path to acceptance was not straight forward and on last look I considered there still to be controversy. In this RFC, this aspect is not presented, and provides a biased opinion on the matter.

So what are the benefits to Arch users? Some improved debugging is useful for a distro using new releases of software, but the advantage of what is provided in our current debug info is in my opinion limited in practice. I see the main advantage as coming down to performance monitoring. My conclusion is this is a gain for the minority of users, at the expense of the majority. I see the ratio of gain/loss as being more acceptable for RedHat and Ubuntu LTS, but they do not have the same use case as Arch. Compare this to the security flags we have added, which are a gain for all users, and generally with less uncertain performance hits.

After spending a lot of time looking at adding these flags, I can not conclude this is currently a good move for Arch Linux.

changed the description

As a user who's not doing distro development, I don't find that I have a need for frame pointers in official packages. When I'm profiling an application, it's almost always for something that hasn't been officially released yet, so I'm building from source anyway and I can enable the frame pointer myself. Since there is going to be a performance penalty, I'd prefer for Arch to leave it disabled.

added 1 commit

66a025cc - Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Compare with previous version

If there are no further comments on the proposal itself within the next days I'll move this proposal forward for the final discussion period.

I've come around to believing this is really important to have. When most libraries on the system are missing frame pointers, performance profiling of any dynamically linked program is basically a non-starter. The overall performance impact on our users should not be noticeable, but we can reevaluate this after it has been deployed.

added 1 commit

ea931f67 - Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Compare with previous version

approved this merge request

To the best of my knowledge developers using Arch are in the are dozens if not hundreds - both directly of via any of the derivatives like Manjaro, ChimeraOS, SteamOS, etc. Those include kernel developers, game developers and everything in between.

I am not sure how many of those dogfood their work - personally I do.

For most of my perf related work, rebuilding 1-2 projects/packages + manually adding the -fno-omit-frame-pointer was tad annoying, but nothing more.

Some of my day-job is managing SteamOS 3 and from personal capacity I would say:

yes, there is interest in Arch being a developer friendly environment, where this proposal helps
having a way to opt-out, for performance/other reasons, would be deeply appreciated

I believe some if not all of the above have already been raised and answered. Just sharing my POV as someone who has been using Arch for over a decade and their work involves using Arch as a base.

HTH o/

approved this merge request

Beyond a rejection from Allan, this proposal has only had positive approvals from the team.

Thus I consider it approved and can be implemented.

We'll do a review in 6-7 months time but for that to happen we should try and get most of the core packages rebuilt when the flags have landed.

https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux.org/thread/TJ7AQQMWSRLL6ZSLXZ56PVK3CCVB6TNM/

This can now be merged.

Mostly changing some links to actually be proper embedded rST hyperlinks making them directly clickable in the rendered rST rather than having to copy/paste the URLs.

While doing so I also ‘accidentally’ improved the link texts of the affected links to a lesser or greater extent which I recognise does change the text of the RFC slightly (though I believe these changes do not change any actual meaning). If the change needs to be rejected on this basis as the RFC has already been approved with the existing wording, an s/>`/>`_/ should be sufficient to bring the main purpose of this comment/review to effect.