Bug#334119: Patch to prevent open_not_cancel etc. from being inlined; needed for Plash's modified glibc
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
Reply to: