glibc SFrame support for newer versions

[Florian Weimer]

* 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 think it will be impossible to test v2 objects soon enough because
there's no toolchain left that produces it.

We have the same issue with DWARF unwinding, where there are many code
paths that aren't used today with correctly linked binaries.  Sometimes
we learn about bugs in them only because of linkers that produce corrupt
binaries.

>>> 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).

Or move those symbols into a separate DSO that has a real dependency on
libgcc_s.  Out of 648 processes on my system, 258 already use libgcc_s.
(Only 94 use libstdc++.)  Maybe even unconditional loading would be
acceptable.  The numbers are from Fedora, though, which builds with
-fexceptions, which tends to add extra libgcc_s references in shared
objects which use __attribute__ ((cleanup)), including NSS modules
provided by systemd.

Thanks,
Florian