Re: glibc ABI symbol list checking

[Roland McGrath <roland at redhat dot com>]

Sorry I led this slide.  I wanted to do something to deal with the known
difference for TLS builds vs not (errno et al) before committing reference
lists.  I've put in an adequate kludge for this now.

The kludge is that the tuple actually used for check-abi is tuple/tls or
tuple/notls.  So the common parts are in the .abilist file under
cpu-.*-linux.* and that matches either, while errno et al are under
cpu-.*-linux.*/notls and that doesn't match for a TLS build.  It's a little
tricky for doing update-abi.  There's a kludge in the merging script so
that we don't get both /notls and /tls listed when one .* pattern will do.
You have to know which one is the subset, so I do
	make update-abi update-abi-config='i.86-.*-linux.*'
in the TLS build and then
	make update-abi update-abi-config='i.86-.*-linux.*/notls'
in the no-TLS build and get a merged file that passed check-abi on both and
has no duplication.

I cleaned up the makefile rules and fixed some script bugs as well, and
also changed the location of the reference files.  Rather than putting
libfoo.abilist in the source subdir libfoo comes from, I centralize them
all in a single subdir abilist/ under the source directory.  It's probably
nicer to look at them all in one place when staring at them, but the main
reason for this is so that we can have a single reference file for
libpthread and check both NPTL and LinuxThreads against the same ABI.
(Previously the different linuxthreads and nptl source directories would
house libpthread.abilist for the different builds, and so the two would
never be compared.)  (If there are other add-ons that have their own
additional libs where it doesn't make sense to have them represented in the
main glibc sources, we can make the makefiles search the add-on source dirs
for .abilist files as well.)

I don't want to add this source subdir and reference files to the
repository until Ulrich and others agree this is the right plan.

I've made some reference files on the two platforms most convenient for me,
which are i386 linux and powerpc linux, and merged in the x86-64 linux
stanzas from the files you sent in your patch.  You can get those from
http://people.redhat.com/roland/glibc/abilist.tar.bz2 (also works as ftp URL).

If you untar that in your source directory you'll get an abilist/ subdir
and then (after a cvs update) "make check-abi" should work on i.86,
powerpc, or x86-64.  People with other platforms can run
	make update-abi update-abi-config='cpu-.*-linux.*'
to modify the files in abilist/ and then send me the new ones or diffs.

Using check-abi in my various builds highlighted a few problems.

* One of my builds lacks epoll_*, which check-abi caught.
  (Hmm, maybe this is what this whole thing was for!)
  This is because that build was against older kernel headers that don't
  have those syscalls.  It occurs to me that to catch this earlier (during
  the build), we could change the syscalls.list processing to have a mark
  like EXTRA but that would produce the calls unconditionally, or just barf
  in make-syscalls.sh if the syscall is undefined.  This is probably what
  makes sense for EXTRA.  We'd need to have a different one that
  behaves like EXTRA does now, that would be used for the __syscall_*
  entries--those are used by code that does #ifdef __NR_*, so omitting them
  for missing syscalls is fine.  But that idea is just a way to catch these
  during build rather than in make check-abi, and all that really matters
  is that we catch them somehow.

  We want a consistent ABI, so we should either require newer kernel
  headers or build ENOSYS stubs for exported system calls that are missing.

* The reference files I made were with linuxthreads builds, and the NPTL
  build has several differences in libpthread and one in libc.  Most of
  these are symbols defined weak in linuxthreads and strong in nptl.
  Probably we just ought to change linuxthreads to define these strong,
  it's unclear to me why it would define anything weak (unlike libc).  

  There are a couple of functions actually missing or new in NPTL, and I
  don't know what the story is with those.  I think we want these ABIs to
  match, and that's why having a central libpthread.abilist makes sense.


Enjoy,
Roland