From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9006 invoked by alias); 26 Mar 2003 20:23:50 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 8990 invoked from network); 26 Mar 2003 20:23:49 -0000 Received: from unknown (HELO myware.akkadia.org) (24.221.190.179) by sources.redhat.com with SMTP; 26 Mar 2003 20:23:49 -0000 Received: from redhat.com (myware.akkadia.org [192.168.7.70]) (authenticated bits=0) by myware.akkadia.org (8.12.8/8.12.5) with ESMTP id h2QKNViG027941; Wed, 26 Mar 2003 12:23:31 -0800 Message-ID: <3E820C42.8090709@redhat.com> Date: Thu, 27 Mar 2003 00:20:00 -0000 From: Ulrich Drepper Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland McGrath CC: GNU libc hacker Subject: Re: abilist problems References: <200303260101.h2Q11ut08619@magilla.sf.frob.com> In-Reply-To: <200303260101.h2Q11ut08619@magilla.sf.frob.com> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00109.txt.bz2 -----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 #ifdef __NR_ PSEUDO (, , N) ret PSEUDO_END () #else PSEUDO_UNAVAIL (, 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-----