glibc SFrame support for newer versions

[Adhemerval Zanella Netto]

On 25/11/25 17:29, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> My point is how we should handle glibc SFrame support in upcoming
>> versions, especially given potential mismatches across
>> libraries. Would just bump support to v3 and ignore v2 objects, as we
>> currently do on sframe_header_sanity_check_p for v1?
> 
> It depends on whether there any v2 objects in circulation at all.  The
> format is simple enough that we could include parsers for both versions.

It does complicate testing, specially when we have different objects with
different SFrame versions along with toolchain that supports versions.

> 
>> I wonder if it would be better to make it similar to how we handle
>> libgcc_s.so and move the sframe support to a library outside glibc
>> (so any supported version would be handled by the system libraries,
>> instead of glibc itself).
> 
> No, dynamic loading of backtracing code when you need them is not such a
> great idea.
> 
> Given how stable the DWARF unwind data is (despite occasional concerns
> about the opposite), I'd rather see glibc using a built-in unwinder for
> that, too.

One possibility that I though, but I haven't implement; is forcing libgcc_s.so
load at loading time instead of in-demand if the binary has binding for
the symbol that require it (like pthread_cancel/pthread_exit/backtrace).