Re: cope with varying prelink base addresses

[Kevin Buettner <kevinb at redhat dot com>]

On Mon, 13 Feb 2006 17:03:30 -0200
Alexandre Oliva <aoliva@redhat.com> wrote:

> On Feb  9, 2006, Daniel Jacobowitz <drow@false.org> wrote:
> 
> > On Thu, Feb 09, 2006 at 10:08:47PM -0200, Alexandre Oliva wrote:
> >> > 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.
> 
> > No, Alexandre, Mark is talking about something that we actually
> > experienced.  The interpretations are _not_ the same when the base
> > address in the program header is non-zero.  There was at least
> > one dynamic loader which set l_addr to the absolute address
> > the segment was loaded to, even though the program header's l_addr
> > was non-zero.
> 
> Yuck.  Fair enough.  Anyhow, I don't see any evidence that GDB
> actually supports any such broken l_addr semantics, so it's not like
> the patch would be breaking anything.  If anything, it would be
> enabling gdb to work on such a system work, assuming l_ld is set up
> correctly.

I agree.  (I've been careful to not let in any patches which would support
alternate l_addr semantics.)

I've been looking over your patch and would like to see it committed
so long as it receives a some more testing first.  Would it be possible
for you to test it on Solaris system and a BSD system?

Kevin