This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libc question


On Mon, 31 Jul 2006, David Brown moaned:
> I've googled for a week (on and off) trying to find information about
> doing this and the only things I've found were from 1998 on the
> libc-hackers ml that's been shutdown. From the conversation there,
> some of the other reasons were userspace code using the __libc_open
> and __open directly in their code.  I'm curious to see any
> conversation on the performance of glibc using internal __open vs.
> using open directly.

If calls to such routines are to be overrideable by other shared objects
(preloaded or no), then they must go though the PLT, which incurs
additional relocation costs, and additional costs on every call. The
relocation costs can be minimized by using prelink, but the per-call
costs can't be.

The speedup to glibc attributable to pruning the PLT of such internal
symbols is quite significant; large enough that the loss of flexibility
was considered acceptable.

A custom-built C library (whether glibc or some other one) really is the
best way to do this.

-- 
`We're sysadmins. We deal with the inconceivable so often I can clearly 
 see the need to define levels of inconceivability.' --- Rik Steenwinkel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]