This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: cope with varying prelink base addresses
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