glibc SFrame support for newer versions
Florian Weimer
fweimer@redhat.com
Tue Nov 25 20:29:36 GMT 2025
* 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.
> 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.
Thanks,
Florian
More information about the Libc-alpha
mailing list