On 11/22/22 10:19, Florian Weimer wrote:
* Neal Gompa:
> On Tue, Nov 22, 2022 at 6:54 AM Florian Weimer <fweimer(a)redhat.com> wrote:
>>
>> Why isn't this something that is up to the toolchain team to decide?
>>
>
> The toolchain team doesn't work with the full corpus of packages,
> doesn't really interface with most of the packagers, and doesn't work
> with most of the upstreams that make up Fedora. So by that definition,
> the toolchain team can't decide either.
Still I think this interferes *a lot* in an area that should the package
maintainer's prerogative.
As of today, we do not have patches to build glibc with frame pointers
on most architectures. Someone said on the ticket that they have done
it, but they haven't upstreamed their patches. The individual changes
may be tiny, but just for x86-64, roughly 500 assembler files need
patching. I just don't see us maintaining this as a downstream-only
patch. And without these patches, the most widely used glibc functions
(by executed instructions) won't have frame pointers.
IIRC the initial motivation for this was profiling requirements at Meta.
Could they pay one or two people to actually make profiling work on Linux
*without* frame pointers, instead of slowing everyone’s system down by
requiring them? I have already proposed a solution (do the stack
unwinding in the vDSO) which makes this possible *without* having to
parse untrusted DWARF in kernel mode. This does mean moving the
unwinding out of NMI context, but that is highly desirable *anyway*,
as it means being able to page in memory as needed. If unwinding
*really* needs to be done in kernel mode, this would be a good use of
the recently-added Rust support. At this point, it is a matter of
paying someone to actually do the work, not of whether the work is
possible.
--
Sincerely,
Demi Marie Obenour (she/her/hers)