This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: stackable abilist files
On Sat, 21 Apr 2012, Mike Frysinger wrote:
> i can't see how duplicating ~80K of data 10 times is an improvement. if we
> really want to insist on splitting the files, i think we should rework the
> scripts/data formats so arches can override only the pieces they need.
I'd say the point of these files is to duplicate information that is
elsewhere (Versions files etc.) in a simpler form that's less prone to
accidental changes - and simplicity of having a completely explicit
expected baseline for each architecture, rather than something with less
duplication but made up of pieces in different locations (with an
increased risk that a change to sysdeps directories changes both the
expected baseline and the versions used, so causing check-abi to fail to
detect a problem, for example), is a virtue here.
Note that new architectures will usually set a minimum symbol version in
shlib-versions, so requiring different versions for all existing symbols
from architectures added in different versions. This also limits the
extent of possible sharing. I suppose you could define named symbol sets
in common files and then make the architecture-specific files refer to
those symbol sets (giving an architecture-dependent version to them)
rather than listing most symbols directly. But I don't really think such
complexity is worthwhile.
Question: has anyone actually run check-abi on architectures other than
x86 or x86_64 lately? Looking at the libc baseline I see for example
__fentry__ listed under GLIBC_2.13 for more architectures than just x86
and x86_64 which actually define and use it, while fallocate64 is listed
under GLIBC_2.11 only for x86, GLIBC_2.10 for all other architectures (but
it was a general issue for 32-bit architectures that they didn't get it
until 2.11). Maybe powerpc, s390 and sh maintainers should run it for
their targets (both 32-bit and 64-bit variants, where applicable) to check
that the recent data there is actually correct for them, and fix it as
needed.
--
Joseph S. Myers
joseph@codesourcery.com