[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