[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> > > 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: