* enable_break() in solib-svr4.c @ 2005-08-15 20:21 Paul Koning 2005-08-15 20:59 ` Mark Kettenis 2005-08-31 20:31 ` Kevin Buettner 0 siblings, 2 replies; 7+ messages in thread From: Paul Koning @ 2005-08-15 20:21 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: enable_break() in solib-svr4.c 2005-08-15 20:21 enable_break() in solib-svr4.c Paul Koning @ 2005-08-15 20:59 ` Mark Kettenis 2005-08-31 20:31 ` Kevin Buettner 1 sibling, 0 replies; 7+ messages in thread From: Mark Kettenis @ 2005-08-15 20:59 UTC (permalink / raw) To: pkoning; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: enable_break() in solib-svr4.c 2005-08-15 20:21 enable_break() in solib-svr4.c Paul Koning 2005-08-15 20:59 ` Mark Kettenis @ 2005-08-31 20:31 ` Kevin Buettner 2005-08-31 21:14 ` Paul Koning 2005-08-31 21:19 ` Mark Kettenis 1 sibling, 2 replies; 7+ messages in thread From: Kevin Buettner @ 2005-08-31 20:31 UTC (permalink / raw) To: Paul Koning; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: enable_break() in solib-svr4.c 2005-08-31 20:31 ` Kevin Buettner @ 2005-08-31 21:14 ` Paul Koning 2005-08-31 21:20 ` Daniel Jacobowitz 2005-08-31 21:19 ` Mark Kettenis 1 sibling, 1 reply; 7+ messages in thread From: Paul Koning @ 2005-08-31 21:14 UTC (permalink / raw) To: kevinb; +Cc: gdb >>>>> "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: enable_break() in solib-svr4.c 2005-08-31 21:14 ` Paul Koning @ 2005-08-31 21:20 ` Daniel Jacobowitz 2005-08-31 21:40 ` Paul Koning 0 siblings, 1 reply; 7+ messages in thread From: Daniel Jacobowitz @ 2005-08-31 21:20 UTC (permalink / raw) To: Paul Koning; +Cc: kevinb, gdb 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: enable_break() in solib-svr4.c 2005-08-31 21:20 ` Daniel Jacobowitz @ 2005-08-31 21:40 ` Paul Koning 0 siblings, 0 replies; 7+ messages in thread From: Paul Koning @ 2005-08-31 21:40 UTC (permalink / raw) To: drow; +Cc: kevinb, gdb >>>>> "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: enable_break() in solib-svr4.c 2005-08-31 20:31 ` Kevin Buettner 2005-08-31 21:14 ` Paul Koning @ 2005-08-31 21:19 ` Mark Kettenis 1 sibling, 0 replies; 7+ messages in thread From: Mark Kettenis @ 2005-08-31 21:19 UTC (permalink / raw) To: kevinb; +Cc: pkoning, gdb > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-08-31 21:40 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-08-15 20:21 enable_break() in solib-svr4.c Paul Koning 2005-08-15 20:59 ` Mark Kettenis 2005-08-31 20:31 ` Kevin Buettner 2005-08-31 21:14 ` Paul Koning 2005-08-31 21:20 ` Daniel Jacobowitz 2005-08-31 21:40 ` Paul Koning 2005-08-31 21:19 ` Mark Kettenis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).