Re: abilist problems

[Roland McGrath <roland at redhat dot com>]

Sorry I didn't respond quicker.

Firstly, it is certainly trivial to disable check-abi if it is hampering
you.  Just comment out "tests: check-abi" in Makerules.  But I would
just use "make -k check" and ignore the check-abi failures for now if I
were you.  The reason I turned it on last week was that I figured it was
ready for us to have all the reference lists installed, use it daily,
and work out the kinks.

I can add a make variable and configure option to disable check-abi
being part of make check.  Even check-abi bugs per se aside, that is
something I can imagine wanting during certain periods of development,
i.e. if you are adding functions or a new port and don't want to bother
with the visual double-check and update-abi run until you're ready to
commit or make a test release or whatever.

As to both the system calls and _nl_default_dirname, I don't think these
are problems with check-abi.  These are exactly the kinds of accidental
ABI differences that I intended it to catch.  

_nl_default_dirname needs to be a consistent size if it's the same ABI.
The canonical size is 0x12, which is sizeof "/usr/share/locale".  If it
is larger, then executables that use it will have copy relocs that won't
contain the whole initializer string from libc.so.6 and the program will
be using an unterminated string.

Now that it's been pointed out, I've noticed that _nl_default_dirname
has bogus different sizes in the sh and powerpc64 lists I've been sent.
This must be from builds not using --prefix=/usr, and I don't know any
reason why that should be done.  (If you do some hack build for
debugging or whatever, don't use check-abi/update-abi in that build.)

If people really do production builds for *-*-linux* configs using
something other than --prefix=/usr, then I can do something to represent
them in the check.  But I am skeptical that such is really necessary.


Now, about the system calls.  As I said, this is exactly the kind of
"silent build error" I intend check-abi to catch.  For all the usual
reasons, you never want to have two builds for the same platform that
differ in what set of symbols each given soname+setname includes.
soname+setname is the granularity of dependency tracking by packaging
systems, humans, and everything else.

If a function is intended to be a general part of the user API, the
proper thing to do is to give it a sysdeps/generic stub, and a
declaration in a non-sysdeps header or a sysdeps/generic version of the
relevant header.  If you do that, you always get the function in the ABI
even if just an ENOSYS stub.  Then how your build went is just a runtime
usability issue, and not an ABI compatibility issue at the symbol level.

When I wrote the syscalls.list mechanism, I did not anticipate the
practice of using EXTRA to add system calls unrelated to anything in any
makefile.  I still don't like it, because it encourages adding things to
the API/ABI willy-nilly for one configuration without regard to the
common glibc API and keeping it consistent across all GNU systems.

But if syscalls.list is going to be used to add things to the API/ABI,
then I think it should be a rigid source specification of what goes in.
That is, the API and ABI should not be affected by what headers you
compile with.  The simplest thing is to make it a build error to have
the syscall number missing for an EXTRA syscall.  Then if you've added
new syscalls and try a build with an older kernel's headers, you will
lose.  (It's also pretty simple to through in a configure-time check for
these so that you can be told at configure time to try again using
--with-headers instead of just losing when you run make.)

It's not much harder to make it generate ENOSYS stubs for EXTRA syscalls
whose numbers are not defined.  

It's also easy enough to amend syscalls.list with a way to specify the
numbers directly.  But that is just another set of bits to maintain.  If
you want to do that, then you are punting on getting those bits from the
kernel headers and then I don't see why you wouldn't just maintain
sysdeps/.../syscall.h files with complete lists by hand.

I can implement any syscall generation change you like quickly enough.


Thanks,
Roland