Re: Memory statistics



On Sat, 2006-04-22 at 22:54 +0200, David Turner wrote:
> -  each PLT slot it is made of code that is updated lazily on usage by
> the dynamic linker (i.e. during program execution, not at load time).
> If you want to share them, you'd  better be sure that this is done in
> a way that is safe from concurrent updates

	I think you're confused here - at least, for the architecture I'm using
(x86/x86_64) the .plt is RO/sharable & executable, .rel.plt is
RO/sharable/non-exec, and of course all the real .plt fixups occur in
the GOT section, as you would expect.

> > ... or on OpenOffice.  Michael "I want to be like him when I grow up -
> > oh, wait, he's younger than me" Meeks has been kicking some ass in that
> > front.
>   
> I thought his job was about speeding the symbol lookup process, not
> the page sharing bit. If not, that would be a good surprise.

	No work on improving page sharing unfortunately. Of course reducing
relocation count is nice but ... ;-)

> > Wouldn't something like this need to happen:
> > 
> > 	1. program gets run; linker does the fixups
> > 	2. linker writes "libfoo.so got put at 0x12345678, here is a 
> >            list of resolved relocations: <...>"
> > 	3. another program gets run.
> > 	4. linker looks in its archive from (2) to see if it had
> > 	   already resolved libfoo.so at some address.

	This sounds like a simple description of prelink (no ?).

> Apart from that, you'll get relocations.

	Honestly - the more I look at the picture, the more I think using a
'kdeinit' type approach might be rather better - at least for the core
apps: nautilus, panel etc.

> I'm interested however in any specific point that would show why this
> couldn't be implemented for specific projects like OLPC, which
> probably don't need all the whiz-bang features (and misfeatures) of
> ELF dynamic linking.

	Sure OLPC should be using some variant of linking the entire system
statically into a single executable, pre-initialized image, discarding
all symbols, .plt, .rels, init code, etc. etc. ;-) [ at least, I'd guess
you can pull some nice tricks that way if you try ].

	HTH,

		Michael.

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




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