From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12545 invoked by alias); 26 Mar 2003 01:01:58 -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 12529 invoked from network); 26 Mar 2003 01:01:57 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.160.55.131) by sources.redhat.com with SMTP; 26 Mar 2003 01:01:57 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id A0D1B354C; Tue, 25 Mar 2003 17:01:56 -0800 (PST) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h2Q11ut08619; Tue, 25 Mar 2003 17:01:56 -0800 Date: Wed, 26 Mar 2003 01:02:00 -0000 Message-Id: <200303260101.h2Q11ut08619@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Ulrich Drepper Cc: GNU libc hacker Subject: Re: abilist problems In-Reply-To: Ulrich Drepper's message of Monday, 24 March 2003 11:13:25 -0800 <3E7F58D5.4020602@redhat.com> X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. X-SW-Source: 2003-03/txt/msg00098.txt.bz2 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