[PATCH 0/6] Re: glibc: Add SFrame support for stack backtracing
Sam James
sam@gentoo.org
Wed Jul 16 03:39:41 GMT 2025
Xi Ruoyao <xry111@xry111.site> writes:
> On Wed, 2025-07-16 at 04:18 +0100, Sam James wrote:
>> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>>
>> > On 15/07/25 13:27, Indu Bhagat wrote:
>> > > On 2025-07-15 3:42 a.m., Claudiu Zissulescu-Ianculescu wrote:
>> > > > Hi,
>> > > >
>> > > > Looks like is this one:
>> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=32298
>> > > >
>> > > > But let's wait Indu input,
>> > > > Claudiu
>> > > >
>> > >
>> > > Hi,
>> > >
>> > > Looks like this one: //sourceware.org/bugzilla/show_bug.cgi?id=32297
>> > >
>> > > Some of the other known issues affecting glibc builds are listed here https://sourceware.org/binutils/wiki/sframe#Support_SFrame_based_stack_tracing_in_glibc_backtrace
>> > >
>> > > BTW, moving forward, since in Binutils 2.45 we are generating SFrame
>> > > section with a new type SHT_GNU_SFRAME (previous versions were
>> > > emitting section type SHT_PROGBITS), we need to encourage users to
>> > > start using Binutils 2.45.
>> > >
>> >
>> > So we need to either disable SFRAME when building glibc with a broken
>> > binutils and/or backport theses fixes on the affected binutils branches.
>>
>> My position is we should require 2.45 for glibc SFrame
>> support. Distributions or people building manually don't always pick up
>> the fixes on branches.
>
> Or make autoconf probe if binutils can generate SFrame properly.
I don't think that's going to be feasible here. We'd need to quickly
have suitable probes that have little risk of false positives. There's a
bunch of issues that aren't fixed in 2.44.
More information about the Libc-alpha
mailing list