On Sun, Oct 16, 2005 at 05:15:45PM +0100, Mark Seaborn wrote: > 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 would be amazed if upstream took it. They are not generally tolerant of this sort of limited-use-large-effect change. > > 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? Unlikely. Most people need to intercept all syscalls, not just most. It's not useful for that. > 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. Correct. It wouldn't anyway; Linux 2.4 did not have a vsyscall. I would have thought it would work with the NPTL build, but I didn't check. > > > 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? Definitely not a new package. > > 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. Huh? Then why did your patch need to modify NPTL? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
