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 Saturday 21 April 2012 12:57:21 Joseph S. Myers wrote:
> 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.

we could have the abilist code leverage shlib-versions by default since that's 
what the values should be in the first place instead of duplicating that base 
symbol name in both places.  that should address the majority of symbol 
duplication information (functions with symbol version bases).

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

if it isn't in default `make check`, people forget.  since we run things like 
checkplt in the default check, i don't see any reason to also include abi 
checking (but we have a thread on that topic).
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


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