glibc SFrame support for newer versions

[Adhemerval Zanella Netto]

On 26/11/25 12:41, Florian Weimer wrote:
> * 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.

Which circles back the my original question whether should we keep 
the v2 support and just replace once v3 becomes the current one. 

I think if/when we set --enable-sframe as default we might not have
this freedom.

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

This works, but I am not sure we can add a DT_NEEDED of libgcc_s.so on 
libc.so without adding some extra complication on bootstrap.  That's why
I was thinking is making it an 'implicit' dependency might works better.
We can use a similar strategy with backtrace and a possible libsframe.so.