cope with varying prelink base addresses

[Alexandre Oliva]

If you take a core file created on a box whose libraries have been
prelinked with random base addresses and try to use it for debugging
on another box that has the very same binaries, but prelinked with a
different base address, gdb will get all confused.

That's because the load_addr of the prelinked binaries will be
whatever difference there was between the base address selected by
prelink and the base address used at run time by the dynamic loader.
If everything is prelinked successfully, the load addresses will all
be zero.

So when gdb reads the binary prelinked with a different base address,
and applies to it the load address read from the core file, it won't
get the correct address if the prelinked binary on the debugging host
got a different address.

This is arguably a change in the binary, so debugging is not expected
to work anyway, but it definitely is surprising, especially when
prelink is enabled by default.  This would render core files useless
across different hosts.

This patch gets gdb to try to recognize the situation in which a
binary got prelinked but is otherwise unchanged, and figure out the
difference between the base addresses at core-generating host and at
the debugging host.

The only piece of information available for this that I could find was
the address of the dynamic table in the dynamic loader data
structures.  The heuristics I used was to check whether the dynamic
table address changed but remained at the same position within a
page.  If so, I assume the difference is caused by prelinking, and
then I adjust the load_addr that gdb is going to use for that binary.
Otherwise, it will face the same problems you're expected to face when
debugging a core file using a different binary.

I'd appreciate if whoever reviews this would pay particular attention
to the gdb testcase; it's the first time I write one, and I could use
some guidance to make sure I'm not making undeserved assumptions.
It's bad enough that I have to use compile- and run-time flags that
will likely only work with GCC and GNU ld, and that the test requires
the prelink program to be in the PATH; I hope I'm coping well with
cases in which the flags are not accepted or prelink is not in place.

Comments?  Ok to install?  Tested on amd64-linux-gnu.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-prelink-core-2.patch
Type: text/x-patch
Size: 15222 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20060208/ec83b9c0/attachment.bin>
-------------- next part --------------

-- 
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}