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