enable_break() in solib-svr4.c

enable_break() in solib-svr4.c

[Paul Koning]

The code in solib-svr4.c in several places seems to assume that the
shared lib loader is linked to base address 0, loaded somewhere else,
and relocated at runtime -- and ditto for other libraries. 

I've just been battling a bug in enable_break, where the load address
of the shared lib loader is added to a symbol address from the
solib_break_names[] list.  That produces nonsense on NetBSD/MIPS,
because ldd.elf_so is linked to 5ffe0000 so that address is added to
the symbol address (5ffexxxx).

As a hack solution I have it add the load address only if the symbol
value is less than the load address.  It seems to me the correct way
to cure this is to compute the relocation delta -- the difference
between the load address and the as-linked VMA of the start of the
library (from the program headers).  I did something like this in
svr4_relocate_section_addresses. 

	 paul

Re: enable_break() in solib-svr4.c

[Mark Kettenis]

> Date: Mon, 15 Aug 2005 16:20:59 -0400
> From: Paul Koning <pkoning@equallogic.com>
> 
> The code in solib-svr4.c in several places seems to assume that the
> shared lib loader is linked to base address 0, loaded somewhere else,
> and relocated at runtime -- and ditto for other libraries. 
> 
> I've just been battling a bug in enable_break, where the load address
> of the shared lib loader is added to a symbol address from the
> solib_break_names[] list.  That produces nonsense on NetBSD/MIPS,
> because ldd.elf_so is linked to 5ffe0000 so that address is added to
> the symbol address (5ffexxxx).

I seem to recall that we have had problems with this in the past, and
that MIPS is a bit of an odd one out in this respect.  I also seem to
recall that NetBSD/MIPS changed some data structures in the dynamic
linker which doesn't make things easier for gdb.  What version of
NetBSD are you using?

> As a hack solution I have it add the load address only if the symbol
> value is less than the load address.  It seems to me the correct way
> to cure this is to compute the relocation delta -- the difference
> between the load address and the as-linked VMA of the start of the
> library (from the program headers).  I did something like this in
> svr4_relocate_section_addresses. 

It'd help if you actually attached your solution ;-).

Mark

Re: enable_break() in solib-svr4.c

[Kevin Buettner]

On Mon, 15 Aug 2005 16:20:59 -0400
Paul Koning <pkoning@equallogic.com> wrote:

> The code in solib-svr4.c in several places seems to assume that the
> shared lib loader is linked to base address 0, loaded somewhere else,
> and relocated at runtime -- and ditto for other libraries. 
> 
> I've just been battling a bug in enable_break, where the load address
> of the shared lib loader is added to a symbol address from the
> solib_break_names[] list.  That produces nonsense on NetBSD/MIPS,
> because ldd.elf_so is linked to 5ffe0000 so that address is added to
> the symbol address (5ffexxxx).
> 
> As a hack solution I have it add the load address only if the symbol
> value is less than the load address.  It seems to me the correct way
> to cure this is to compute the relocation delta -- the difference
> between the load address and the as-linked VMA of the start of the
> library (from the program headers).  I did something like this in
> svr4_relocate_section_addresses. 

I too would like to see your solution, hack or not.

Is this issue different than the ones already discussed as part of the
following thread?

http://sources.redhat.com/ml/gdb/2002-12/msg00266.html

Kevin

Re: enable_break() in solib-svr4.c

[Paul Koning]

>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

 Kevin> On Mon, 15 Aug 2005 16:20:59 -0400 Paul Koning
 Kevin> <pkoning@equallogic.com> wrote:

 >> The code in solib-svr4.c in several places seems to assume that
 >> the shared lib loader is linked to base address 0, loaded
 >> somewhere else, and relocated at runtime -- and ditto for other
 >> libraries.
 >> 
 >> I've just been battling a bug in enable_break, where the load
 >> address of the shared lib loader is added to a symbol address from
 >> the solib_break_names[] list.  That produces nonsense on
 >> NetBSD/MIPS, because ldd.elf_so is linked to 5ffe0000 so that
 >> address is added to the symbol address (5ffexxxx).
 >> 
 >> As a hack solution I have it add the load address only if the
 >> symbol value is less than the load address.  It seems to me the
 >> correct way to cure this is to compute the relocation delta -- the
 >> difference between the load address and the as-linked VMA of the
 >> start of the library (from the program headers).  I did something
 >> like this in svr4_relocate_section_addresses.

 Kevin> I too would like to see your solution, hack or not.

 Kevin> Is this issue different than the ones already discussed as
 Kevin> part of the following thread?

 Kevin> http://sources.redhat.com/ml/gdb/2002-12/msg00266.html

No, it's the same issue, materializing in a second place.

The same conclusion applies as before: either NetBSD is wrong -- it
should use the bizarre and unintuitive meaning of "base address" that
appears to be intended by the document you quoted -- or NetBSD is
right, "base address" means "the address where the thing ended up"
(which is the intuitive definition) and GDB is wrong in several
places.

The reason I'm picking on the meaning of "base address" is that
"address" normally means a place, not a difference.  If people mean
difference, the normal term used is "offset" or "displacement" or
something like that.  So I find it hard to believe that "base address"
is meant to be a difference between two addresses.

It's not an issue that's commonly seen, because the vaddr in a shared
library is nearly always zero.  Nearly always, but not in MIPS/NetBSD,
which is why I ran into this.

I still have no further data from anyone more knowledgeable about
NetBSD as to whether this should be viewed as a NetBSD dynamic loader
bug.

	paul

Re: enable_break() in solib-svr4.c

[Mark Kettenis]

> Date: Wed, 31 Aug 2005 13:30:45 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> On Mon, 15 Aug 2005 16:20:59 -0400
> Paul Koning <pkoning@equallogic.com> wrote:
> 
> > The code in solib-svr4.c in several places seems to assume that the
> > shared lib loader is linked to base address 0, loaded somewhere else,
> > and relocated at runtime -- and ditto for other libraries. 
> > 
> > I've just been battling a bug in enable_break, where the load address
> > of the shared lib loader is added to a symbol address from the
> > solib_break_names[] list.  That produces nonsense on NetBSD/MIPS,
> > because ldd.elf_so is linked to 5ffe0000 so that address is added to
> > the symbol address (5ffexxxx).
> > 
> > As a hack solution I have it add the load address only if the symbol
> > value is less than the load address.  It seems to me the correct way
> > to cure this is to compute the relocation delta -- the difference
> > between the load address and the as-linked VMA of the start of the
> > library (from the program headers).  I did something like this in
> > svr4_relocate_section_addresses. 
> 
> I too would like to see your solution, hack or not.
> 
> Is this issue different than the ones already discussed as part of the
> following thread?
> 
> http://sources.redhat.com/ml/gdb/2002-12/msg00266.html
> 
> Kevin

Did I reply to your origional message Paul?  Or did I let it slip
through?  MIPS is rather special; IRIX apparently did things
differently than everybody else, and some of the open source OS'es
copied the IRIX behaviour for their MIPS ports.  This is the case on
NetBSD/mips; see that #ifdef __mips__ in /usr/include/link_elf.h?

NetBSD made some changes between 1.6 and 2.0 to "rectify" this; and
IIRC the current code works fine on 2.0, but not on 1.6.  

That said, we must be careful making assumptions about the address
layout.  The trend is that operating systems randomize the locations
where they put stuff.

Mark

Re: enable_break() in solib-svr4.c

[Daniel Jacobowitz]

On Wed, Aug 31, 2005 at 05:14:36PM -0400, Paul Koning wrote:
> No, it's the same issue, materializing in a second place.
> 
> The same conclusion applies as before: either NetBSD is wrong -- it
> should use the bizarre and unintuitive meaning of "base address" that
> appears to be intended by the document you quoted -- or NetBSD is
> right, "base address" means "the address where the thing ended up"
> (which is the intuitive definition) and GDB is wrong in several
> places.
> 
> The reason I'm picking on the meaning of "base address" is that
> "address" normally means a place, not a difference.  If people mean
> difference, the normal term used is "offset" or "displacement" or
> something like that.  So I find it hard to believe that "base address"
> is meant to be a difference between two addresses.

I didn't check the thread to see what the "quoted document" was, but
this is from the ELF gABI:

  Because position-independent code uses relative addressing between
  segments, the difference between virtual addresses in memory must match
  the difference between virtual addresses in the file. The difference
  between the virtual address of any segment in memory and the
  corresponding virtual address in the file is thus a single constant
  value for any one executable or shared object in a given process. This
  difference is the base address.

It really doesn't get any clearer than that.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: enable_break() in solib-svr4.c

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Wed, Aug 31, 2005 at 05:14:36PM -0400, Paul Koning wrote:
 >> No, it's the same issue, materializing in a second place.
 >> 
 >> The same conclusion applies as before: either NetBSD is wrong --
 >> it should use the bizarre and unintuitive meaning of "base
 >> address" that appears to be intended by the document you quoted --
 >> or NetBSD is right, "base address" means "the address where the
 >> thing ended up" (which is the intuitive definition) and GDB is
 >> wrong in several places.
 >> 
 >> The reason I'm picking on the meaning of "base address" is that
 >> "address" normally means a place, not a difference.  If people
 >> mean difference, the normal term used is "offset" or
 >> "displacement" or something like that.  So I find it hard to
 >> believe that "base address" is meant to be a difference between
 >> two addresses.

 Daniel> I didn't check the thread to see what the "quoted document"
 Daniel> was, but this is from the ELF gABI:

 Daniel> Because position-independent code uses relative addressing
 Daniel> between segments, the difference between virtual addresses in
 Daniel> memory must match the difference between virtual addresses in
 Daniel> the file. The difference between the virtual address of any
 Daniel> segment in memory and the corresponding virtual address in
 Daniel> the file is thus a single constant value for any one
 Daniel> executable or shared object in a given process. This
 Daniel> difference is the base address.

 Daniel> It really doesn't get any clearer than that.

Other than the fact that it uses the word "address" in a highly
unusual way, I agree, that's pretty clear.  Certainly much more so
than the text quoted in that earlier message.

Ok then, so the conclusion is that NetBSD (in 1.6.2 and before, at
least) violates this rule when it puts the load address, rather than
the difference between load and file addresses, into the "base
address".

Given that bug, I suppose it would make sense to put a target specific
workaround into gdb, i.e., "if the target is NetBSD (or "if the
target is NetBSD-MIPS"??) then 'base address' is not a difference but
just the load address".

That should not be hard.

     paul