This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |