abilist problems

abilist problems

[Ulrich Drepper]

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

I have some big problems with the current abilist implementation.  glibc
always allowed to compile against different kernel headers and have the
resulting binary reflect the kernel the headers are taken from.  This
can cut down on runtime tests for functionality which is known to not be
available since an old kernel is used.

The abilist check causes all such builds to fail.  Syscalls which are
listed only in syscalls.list and are not available in the kernel headers
will have no code created for them.  This in turn obviously results in
differences to the interface.

I see two ways out:

- - make the abilist check optional and/or figure out how to determine
  when the tests can be made mandatory.  E.g., if the kernel header
  version is more recent than x.y.z, make the tests mandatory.

- - create stubs for the syscalls which are not announced in the kernel
  headers.


I probably have a preference for the second solution.  Any volunteer to
hack something?

- -- 
- --------------.                        ,-.            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+f1jV2ijCOnn/RHQRAq93AKCzVJcJDhg5CE/jy5UmvVZusBrD5QCgneZk
YdoDceoehTxT7UyPbfjaoKQ=
=2/qU
-----END PGP SIGNATURE-----

Re: abilist problems

[Andreas Jaeger]

Ulrich Drepper <drepper@redhat.com> writes:

> I have some big problems with the current abilist implementation.  glibc
> always allowed to compile against different kernel headers and have the
> resulting binary reflect the kernel the headers are taken from.  This
> can cut down on runtime tests for functionality which is known to not be
> available since an old kernel is used.

And there's the problem with the _nl_dirname (sp?) symbol which has a
different length depending on the value of --prefix.  We need to find
a way to take this into account without the testsuite failing.

> The abilist check causes all such builds to fail.  Syscalls which are
> listed only in syscalls.list and are not available in the kernel headers
> will have no code created for them.  This in turn obviously results in
> differences to the interface.
>
> I see two ways out:
>
> - make the abilist check optional and/or figure out how to determine
>   when the tests can be made mandatory.  E.g., if the kernel header
>   version is more recent than x.y.z, make the tests mandatory.
>
> - create stubs for the syscalls which are not announced in the kernel
>   headers.
>
>
> I probably have a preference for the second solution.  Any volunteer to
> hack something?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: abilist problems

[Ulrich Drepper]

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

Andreas Jaeger wrote:

> And there's the problem with the _nl_dirname (sp?) symbol which has a
> different length depending on the value of --prefix.  We need to find
> a way to take this into account without the testsuite failing.

I don't consider that a problem.  We have exactly one correct setting
for --prefix.  If it is not the default value there is no need to run
the ABI test since the binary will not be usable in this role anyway.

- -- 
- --------------.                        ,-.            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+f2CN2ijCOnn/RHQRAtwaAJwLbW2Q1a5JEYlvOQhZL6GEhGGC+ACgurTl
eiKUI8WKkBvox8waEFsRrSk=
=hRFI
-----END PGP SIGNATURE-----

Re: abilist problems

[Roland McGrath]

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

Re: abilist problems

[Ulrich Drepper]

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

Re: abilist problems

[Roland McGrath]

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

"configure --disable-check-abi" or "make enable-check-abi=no".

> - - don't take the results serious

What does that mean exactly? "make -k check" is good enough for me.  I have
just added an --enable-check-abi=warn mode, where the diff failures don't
abort make but instead print out "*** WARNING: blah".

> - - this is for real.

The current default (aka --enable-check-abi).

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

I don't know what predicate "we know that some functions will be missing"
is supposed to indicate.  

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

People don't take *** as a warning?  I made it interleaved with the make
check subdir run so that it can be parallelized with other checks, check
each .so's dependencies only once, and have the whole thing finish quicker.

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

It's ok if they produce functions that don't work at runtime.  
It's not ok if they produce binaries that are not dynamic-link-time compatible.

I think if you want to allow that you should use --disable-check-abi.
We could make --disable-sanity-checks disable it too.

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

They also serve as an explicit placeholder in the source.  This provides a
template for what the function looks like, that a port-writer can copy and
edit.  And at least the original convention was to put a comment above the
function giving an informal specification of its interface that in most
cases is enough for a port-writer to know how to implement it.  I think
it's a good thing that this little bit of extra effort and formality be
required, because it makes a person pause and think deliberately about the
interface they are adding.  

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

We do control the glibc API.  Just because a system call is added to Linux
does not mean there must be a function by that name in glibc with the
identical API to the Linux system call.  For the things used only by one or
tow Linux-specific support programs, then people can just call syscall, or
have an extra library for the truly esoteric Linuxisms.  We are stuck with
things like uselib and mount because of the historical mistakes, but we
don't need to worsen it any more now or in the future.

If a new function is of general interest, then it should be investigated
and discussed first whether there is a clean interface that is not
intrinsically kernel-specific that can go into the generic glibc API.  This
was the case with the *xattr functions, for example.  Those got
sysdeps/generic versions and are now a fixed part of the Hurd libc ABI too
(so user programs can be built with xattr support), even though we have not
implemented them on the Hurd yet.

If epoll_* is something that users/application-writers want to use directly
(and not just used to implement some other standard layer like aio), then 
it is also an interface that can be presented cleanly as kernel-independent.
(It's pretty easy to implement for the Hurd, in fact.)

Adding a port-specific API should be the last resort, not the first.


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

It's already impossible to build a glibc you'd want to ship, because it
will be missing some functions that are part of the ABI it claims to support.
If they were made build errors, they could disabled by --disable-sanity-checks.

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

Sorry, I can't make much sense of this paragraph.

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

I have implemented it already, though differently than you described.
All stubs are aliases for a single entry point.



Thanks,
Roland

Re: abilist problems

[Roland McGrath]

If you cvs update you can use make check enable-check-abi=no or
configure --disable-check-abi.

Re: abilist problems

[Steven Munroe]

Roland McGrath writes:

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

The current Suse SLES 8 distro for PPC64 installs the 64-bit tool chain 
as /opt/cross/powerpc64-linux. As this is our current development 
platform we don't build PPC64 with --prefix=/usr.

So it is legitimate for --prefix(es), other then /usr, to be used and 
should be supported for check-abi.

Re: abilist problems

[Ulrich Drepper]

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

Steven Munroe wrote:

> So it is legitimate for --prefix(es), other then /usr, to be used and
> should be supported for check-abi.

No, it is not legitimate.  Only /usr is supported regardless of what you
use.

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

iD4DBQE+gkzN2ijCOnn/RHQRAjgmAKDJh55V60clDl1ikYxHwlr5nlRBpACXadGx
LqLgyTcYJftqXNUodJcaTA==
=1QB8
-----END PGP SIGNATURE-----

Re: abilist problems

[Andreas Schwab]

Steven Munroe <sjmunroe@us.ibm.com> writes:

|> Roland McGrath writes:
|> 
|>  > 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.
|> 
|> The current Suse SLES 8 distro for PPC64 installs the 64-bit tool chain as
|> /opt/cross/powerpc64-linux. As this is our current development platform we
|> don't build PPC64 with --prefix=/usr.

A cross toolchain is special.  The prefix for the target libc should still
be /usr (since that's what the target system will use), but installing it
into the cross tree requires some shuffling and editing so that it works
with the cross compiler.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."