This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

glibc ABI symbol list checking


I've just put in some scripts and makefile hacks that implement some
rudimentary automated checking for accidental changes to the libc ABIs.
This is not really ABI checking, it's symbol list checking.  All that gets
checked is the basic information from the ELF dynamic symbol tables.  Noone
should think this will catch all kinds of compatibility problems, it won't.
It will catch the easy ones early, however.

The basic plan is simply this: We have lists of symbols, and we check newly
each built libraries against the expected list.  The lists of symbols are
the .symlist files created by the script I added a while back.  I modified
that script to produce a more compact format with the same information.
I've added two new scripts and some makefile hacks for doing the checking
and maintenance of "expected" lists.

For each library, there will be a subdir/libfoo.abilist file containing the
expected symbols for that library.  When you do "make check-abi", it will
diff the lists produced from the built libraries against these expected
lists.  Once all the expected data for all the configurations is in place,
we will make this part of "make check".

The way it will stay manageable to maintain these files is that it's
automated.  These files are human-readable, but machine-maintained.  People
are not expected to much with them directly, but should be able to stare at
them and understand what they mean.  

The symbol list differs some for each platform, but we don't want to have
huge numbers of expected list files.  So each .abilist file is a merged
list for many platforms.  To do the comparisons, a script extracts the
current configuration's expected list from the merged master file.

When an ABI change is really correct, you update the .abilist files.  You
never do this by hand, another script does it for you.  When "make check-abi"
fails but you've decided the diffs are correct changes you really want,
then you run "make update-abi update-abi-config=REGEXP" from your build.  
This will update the .abilist files in your source directory based on the
symbol lists from your build.  The REGEXP is how you're identifying the
build, e.g. 'i.86-.*-linux.*', and has to match exactly what's used in the
.abilist file for your configuration already.  This will update your
.abilist source files, and then you have to write change log entries and
submit the changes for review like any others.

I have put in the scripts and makefile hacks to do this, but not yet
committed the initial reference .abilist files.  I have collected symbols
for a couple of platforms and will get some more.  (You can just touch empty
subdir/libfoo.abilist files in your source directory to get started--then
"make check-abi" will fail with a huge diff for each library.)  Once there
are files in place, you can use make update-abi to merge in the symbol list
for your platform.  When we have most of the platforms in the canonical lists,
I will enable the check-abi step as part of "make check" so that it's that
much harder for changes to slip in unplanned.


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