Re: abilist problems

[Ulrich Drepper <drepper at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:

> I can add a make variable and configure option to disable check-abi
> being part of make check.

The configure scripts should be able to set a flag for

- - do not run the script at all.  This should be triggered by a
  --enable-XX option and maybe set by some other means

- - don't take the results serious

- - this is for real.


In the last case make check should fail, in the former not.  The second
flag should be set if, for instance, prefix != /usr, or we know that
some functions will be missing.

If check-abi is run it should always happen dead last and the output
should contain a big warning in case some inconsistency is discovered.



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

Correct.  But some of these builds which are flagged as problematic are
intended to miss functionality.  This is OK if the target kernel is old.
 It is not OK if the default "make check" run fails.


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

No, we should not even think abou this.  Those people are on their own.


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

Of course, but I think it's a waste to have all these unused stubs.
They could be generated.  All they do is set errno to ENOSYS and return -1.


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

At that level there are necessarily differences since we don't control
the Linux kernel and assuming that everything available on Linux will be
available on hurd is probably not very welcome either.


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

This will make it impossible to build glibc without the very latest
headers.  This isn't acceptable.

Instead the code generated in sysd-syscalls could look like this:

#include <sysdep.h>
#ifdef __NR_<syscall>
PSEUDO (<syscall>, <syscall>, N)
ret
PSEUDO_END (<syscall>)
#else
PSEUDO_UNAVAIL (<syscall>, N)
#endif
libc_hidden_def ...
weak_alias ...


The only problematic things here are that the syscall macros differ
among platforms (__NR_xxx on Linux, SYS_xxx elsewhere), and that
makesyscalls has to be changed to emit code even for the EXTRA entries
which have no syscall available.


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

Yes, it's not much harder but not wanted.  Having syscalls macros
available or not will determine code generation.  If I know my code will
only run on 2.2 kernels I don't want to have the dynamic checks for the
new features in my libc.  This is a size and speed issues.  But allowing
glibc to be compiled with whatever kernel header corresponds to the
target system the resulting binary can be optimized for that specific
target.


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

I would like the automatic stub generation I hinted above to be implemented.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ggxC2ijCOnn/RHQRAso5AKC+NvXc18rKHi4gWSZbJ3U6rH406gCbBUxQ
ZhkPQ7ftwCAM+UPR5Ye6Vc4=
=j7b2
-----END PGP SIGNATURE-----