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