Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Sat, Oct 15, 2005 at 06:51:19PM +0100, Mark Seaborn wrote: > > Package: glibc > > Version: 2.3.5-6 > > Severity: wishlist > > Tags: patch > > > > Usually, glibc inlines calls to non-cancellable versions of some > > system calls, such as open_not_cancel. The macro definitions are in > > sysdeps/unix/sysv/linux/not-cancel.h. > > > > This patch prevents those definitions from being inlined. It moves > > them into separate *.c files. > > No way. Two problems: this patch would present an ongoing maintenance > burden for the Debian glibc maintainers, and it would have a > performance impact on all Debian applications on all architectures.
I don't think performance impact should be a real issue with this patch. The NPTL build of glibc doesn't inline these syscalls. Most system calls are not inlined in glibc anyway, and these *_not_cancel calls don't seem to be used from functions that are performance critical. They seem to have been inlined as a convenient way of getting code linked into libpthread.so for Linuxthreads, rather than for performance. I appreciate that it would be a maintenance burden. I'll see if I can get the patch accepted upstream. > I fail to see why the core glibc package should be responsible for > building this rather mauled library. I created a Plash package that built its own copy of the glibc source. I posted an RFS on debian-mentors, and people complained about duplicating glibc. So I changed it to build from libc6-pic. > What's Plash's CPU versions target? For x86, you could probably do > this by: > - replacing the dynamic linker instead of all of glibc > - mapping a fake vsyscall page which checked the syscall number, and > diverted to plash's code if appropriate > - modifying the auxv vector to point at the modified vsyscall dso > instead of the original > - chaining to glibc's standard dynamic linker > > Then you can do it with pristine binaries. Should work on any > architecture which can indirect syscalls through a VDSO (at least ia64, > amd64, possibly soon ppc/ppc64). Interesting idea. Has anyone used the vsyscall mechanism for intercepting syscalls? Having looked into this, one problem is that it won't work with the "libc" and "nptl" builds of glibc that Debian does, because these use "int $0x80" directly. It would only work with the "i686" build. So this won't work with Linux 2.4 or with pre-686 processors. > > This patch isn't quite as essential for putting Plash into Debian as > > the other one I filed in the BTS. > > I am a little dubious about the other Plash bug, but I'll > think about it. It seems marginally within the purview of the > libc6-pic package and affects nothing else. Is your doubt about which package these files would go into, or about these files going into a binary package at all? ie. Would you prefer a new libc6-blah package for putting these files in? > But it seems like it would be randomly crippled without this patch. Randomly injured yes, but a lot of programs would work even if the glibc functions that call *_not_cancel don't work. It would be a useful starting point. As an alternative, I could build Plash from the NPTL build of glibc: the relevant calls are already not inlined. That would involve changing the patch to put the NPTL object files into libc6-pic instead. But it would require Linux 2.6. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
