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: Speeding up the dynamic linker with 100s of DSOs?


Hi Andrew,

On Thu, 2006-01-26 at 14:43 -0800, Andrew Chatham wrote:
> After the call to _dl_map_object_deps(), when all of the required
> objects have been loaded, I build up a table. For every symbol, I
> record the earliest position in the global scope where that symbol
> occurs. I just store the minimum in table[hash(symbol_name)] rather
> than having a real hash table with chaining.

	Ah; ok :-) so - this would burn a chunk of memory for OO.o; we have
~700k individual .dynsym entries kicking around. Of course, with my
-Bdirect approach, we know which symbols are 'vague' and have to be
looked up globally [ ie. ~none for C, and ~25% of my C++ ], and build a
separate hash just for them.

>  Even at 5% of the previous time, they're still slow. So
> I may try your patches at some point, though I'm having enough trouble
> getting this through at the moment.

	Sure - so, you really need to re-compile glibc with -Wl,-hashvals, but
*not* -Wl,-Bdirect; and compile libstdc++ with -Wl,-Bdirect to see a
non-trivial win.

	Interestingly glibc itself (wrt. -lpthread) is the -only- valid/useful
instance of interposing my 'finterpose' tool detects on my system [ only
comparing all DSOs so far ]. OTOH - I've caught 10's of bugs & broken
symbol exports by looking for other examples across the system [ most of
them reported ]. ELF's/Interposing looks to me like an difficult to
justify nightmare - used deliberately only in 1 instance, but used in
error in many others causing unexpected behavior.

	HTH,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot


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