public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* glibc ABI symbol list checking
@ 2002-12-23  3:40 Roland McGrath
  2002-12-26  9:32 ` Andreas Jaeger
  0 siblings, 1 reply; 11+ messages in thread
From: Roland McGrath @ 2002-12-23  3:40 UTC (permalink / raw)
  To: GNU libc hackers

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2003-01-15  8:51 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-23  3:40 glibc ABI symbol list checking Roland McGrath
2002-12-26  9:32 ` Andreas Jaeger
2002-12-26 14:14   ` Roland McGrath
2002-12-27  8:18     ` Andreas Jaeger
2002-12-27 12:30       ` Roland McGrath
2002-12-27 12:34     ` Andreas Jaeger
2002-12-27 12:53       ` Roland McGrath
2002-12-28  5:54         ` Andreas Jaeger
2002-12-28  6:01           ` Jakub Jelinek
2003-01-13  4:59       ` Andreas Jaeger
2003-01-15  8:51         ` Roland McGrath

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).