This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]