Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

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

 



On Tue, Dec 06, 2022 at 05:52:16PM -0000, Andrii Nakryiko wrote:
> > On Tue, Dec 06, 2022 at 03:12:19AM +0000, Gary Buhrmaster wrote:
> > 
> > Note that is not a fully equivalent scenario. The no-omit-frame-pointer
> > proposal was only offering a functional debugging benefit to a fairly
> > small number of users who are also developers, while adding a likely
> > performance hit to all users. There needs to be a high bar to justify
> > the performance hit when the benefit offered is narrow.
> 
> First, frame pointers are not just for debugging benefit. It's not even it's main benefit from POV of https://pagure.io/fesco/issue/2817. Frame pointers are for performance profiling and observability first and foremost, and that's most useful under real-world conditions of production workloads. Not some custom re-built debug versions of applications.
>
> Second, it might benefit a relatively small (but not tiny, it's at least thousands of people doing performance profiling) fraction of users, but those users (developers that care about performance) are the ones bringing benefits to very wide user base.

Yes!  I spent a frustrating time getting perf to record stack traces
properly until I recompiled the program with frame pointers.  (I know
about --call-graph=dwarf but it doesn't seem to work most of the time.)

Rich.

> And third, with appropriate infrastructure of background perf profiling that projects like GNOME and KDE can put in place (if they haven't already), user doesn't have to be involved in performance profiling directly to benefit the ecosystem at large, providing anonymized source of real-world profiling data that could be aggregated and looked at by GNOME/KDE/whatnot developers that do care about performance.
> 
> But this won't happen unless GNOME/KDE can rely on having frame pointers in user systems.
> 
> > 
> > This proposal is adding a functional security benefit to all users,
> > alongside the possible performance hit. This is more easily justifiable,
> > especially given Fedora's track record of being willing to security
> > improvements even when they have a performance hit.
> > 
> > With regards,
> > Daniel
> _______________________________________________
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
_______________________________________________
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