cope with varying prelink base addresses

[Alexandre Oliva]

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.

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