Re: cope with varying prelink base addresses

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb  8, 2006, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> This code is very fragile, and defenitely should be tested on more
> than a single platform.

Seriously, what's fragile about it?  Only if we meet a certain set of
conditions that are only likely to hold in the case of prelinking are
we going to get any change in behavior, and I don't see anything
fragile about the set of conditions.  Sure enough it might not work on
all OSs, but where it does not, it won't make any difference
whatsoever.

> In the past, we've seen that not every OS
> interprets the l_addr field of `struct link_map'.

I don't change in any way the way l_addr is handled.  What I do is
apply an offset atop of l_addr if the conditions are met, where the
conditions are designed to ensure that, if you are to apply it, you'll
be bringing in a definite improvement, rather than perhaps making
things worse.

> And MIPS targets
> have a history of doing things differently even for the same OS.
> Basically the two interpretations are:

> a. l_addr is the absolute address at which the shared object is loaded.

> b. l_addr is the relative address used to relocate the shared object.

Actually, both interpretations are the same.  It looks one or the
other because of the base addresses that appear in the program
headers.  In general, dynamic libraries start at address zero, but
when they're prelinked, they don't, and then l_addr may remain as zero
to reflect that no additional offset was applied.

> The word "heuristic" makes me a bit nervous.  It seems to me that the
> dynamic linker should be able to provide the necessary information.

I don't see how, without duplicating phdr information in read-write
segments, degrading performance and memory use at run time for the
unlikely benefit of a debugger in case of a core dump.

Core files won't contain copies of phdrs or any other read-only
segments, so we can't compare them with what's in the binary to tell
whether we have a match, and comparing modifyable data, that is in the
core file, is unlikely to work, since the data may have been modified.

The only piece of information available to aid the decision is the
dynamic table address.  If the binary changes in any way and you try
to use a core file referencing the other binary, all bets are off
already.  This will just try to increase the odds of proper
functioning in case the only change to the binary was a change in its
base load address, something that prelink and the dynamic loader will
cooperate to do.

> Perhaps you should raise the issue with the glibc developers, to see
> what they can do?

It doesn't make sense for glibc to do anything about this.  We already
have all the information we need, at least as far as glibc is
concerned.

My worry is about other platforms that might represent a different a
different piece of information in l_ld.  For those, we just won't get
a match, and everything will proceed just like it did before, which
I've carefully designed the code to do.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}