Re: cope with varying prelink base addresses

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> From: Alexandre Oliva <aoliva@redhat.com>
> Date: Wed, 08 Feb 2006 03:18:01 -0200
> 
> --=-=-=
> 
> 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.

This code is very fragile, and defenitely should be tested on more
than a single platform.  In the past, we've seen that not every OS
interprets the l_addr field of `struct link_map'.  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.

The confusion arises because many platforms traditionally "pre-link"
at address 0, and then the difference doesn't matter.  I'm afraid my
knowledge of pre-linking isn't detailed enough to check whether this
has any impact on the pre-linking problem.

The word "heuristic" makes me a bit nervous.  It seems to me that the
dynamic linker should be able to provide the necessary information.
Perhaps you should raise the issue with the glibc developers, to see
what they can do?

Mark