From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32026 invoked by alias); 8 Jan 2003 21:52:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31921 invoked from network); 8 Jan 2003 21:52:34 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 209.249.29.67 with SMTP; 8 Jan 2003 21:52:34 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA10587; Wed, 8 Jan 2003 16:44:21 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA24950; Wed, 8 Jan 2003 16:52:21 -0500 Message-ID: <08ab01c2b760$2e6612a0$0202040a@catdog> From: "Kris Warkentin" To: "Paul Koning" , Cc: , "Peter van der Veen" , "Colin Burgess" References: <032c01c2a60a$2368a6e0$0202040a@catdog><1021218002802.ZM4459@localhost.localdomain> <15871.50596.942339.277490@pkoning.akdesign.com> Subject: Re: relocation of shared libs not based at 0 Date: Wed, 08 Jan 2003 21:52:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-01/txt/msg00095.txt.bz2 I've been spending some time chasing this issue since it's fairly important to us. It looks to me like Paul is correct in his assessment that the shared library loader is the problem. Apparently, on NetBSD and QNX, the loader uses the load address of the section as the base address. Linux (and perhaps others) use the difference between the link address and the load address. What I had done to examine this was build shared libs with the normal 0 v_addr and also created some with an ld that had "SHLIB_TEXT_START_ADDR=0xb0300000" (or some such) defined in its linker script. This would give me a library with characteristics like so: kewarken@stimpy:~/test$ objdump -p libodd.so libodd.so: file format elf32-i386 Program Header: LOAD off 0x00000000 vaddr 0xb0300000 paddr 0xb0300000 align 2**12 filesz 0x00000804 memsz 0x00000804 flags r-x Now I wasn't able to get this test to work on Solaris - programs linked to a lib built this way would always crash when the loader ran. On Linux, however, I could link a program to one of these libs and check it out in the debugger. Just as Paul suggested, the run-time linker had filled in the l_addr field in the link_map with 0 so "info shared" would show something like: >From To Syms Read Shared Object Library 0x00000640 0x000007e0 Yes ./libodd.so 0x40037f80 0x40119260 Yes /lib/libc.so.6 instead of: >From To Syms Read Shared Object Library 0xb0300640 0xb03007e0 Yes ./libodd.so 0x40037f80 0x40119260 Yes /lib/libc.so.6 This works fine on QNX and (I assume) NetBSD so it looks rather like we just have a difference of opinion on how the shared object loader should fill things in. We wanted to keep our linker's behaviour for some future enhancements (pre-relocating shared objects on flash memory, etc.) so I was hoping the fix below (Paul's code with some extra comments) might be acceptable. That way Paul and I could just define LM_ADDR_IS_NOT_LOAD_BASE in our tm-.h and we'd be off to the races. static void svr4_relocate_section_addresses (struct so_list *so, struct section_table *sec) { #if LM_ADDR_IS_NOT_LOAD_BASE /* On some platforms, (ie. QNX, NetBSD) LM_ADDR is the assigned address, not the offset. The addresses are formed as follows: LM_ADDR is the target address where the shared library file is mapped, so the actual section start address is LM_ADDR plus the section offset within the shared library file. The end address is that plus the section length. Note that we pay no attention to the section start address as recorded in the library header. */ sec->endaddr = svr4_truncate_ptr (sec->endaddr - sec->addr + sec->the_bfd_section->filepos + LM_ADDR (so)); sec->addr = svr4_truncate_ptr (sec->the_bfd_section->filepos + LM_ADDR (so)); #else sec->addr = svr4_truncate_ptr (sec->addr + LM_ADDR (so)); sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so)); #endif } ----- Original Message ----- From: "Paul Koning" To: Cc: ; Sent: Tuesday, December 17, 2002 7:47 PM Subject: Re: relocation of shared libs not based at 0 > >>>>> "Kevin" == Kevin Buettner writes: > > Kevin> ... > Kevin> So, as I understand it, the "base address" is *not* an > Kevin> absolute location, but is actually the difference between > Kevin> where the segment ended up and the location assigned to it in > Kevin> the executable file. Thus the "base address" is the proper > Kevin> value to use to relocate the segment's start and end > Kevin> addresses. > > That interpretation certainly matches the code. The document you > quoted is not all that clearly worded, but it seems to take the same > view of things. > > On the other hand, the shared library loader in NetBSD doesn't. It > sets the "base address" in the link_map to the load address of the > section, not the bias from the link address to the load address. > That's why I changed solib-svr4.c in my copy of gdb. > > Perhaps a better fix is to change the loader in NetBSD to set "base > address" to match gdb's expectations. > > Kevin> Now, it's possible that my understanding is flawed. If so, I > Kevin> await enlightenment. I think it's also possible that the > Kevin> shared library implementation that you're using might not > Kevin> conform to the above definition of "base address". If that's > Kevin> the case, then you can either attempt to get it fixed in the > Kevin> code which implements the dynamic loader, or, if that's not > Kevin> possible, create a new solib backend for gdb which implements > Kevin> support for your shared library machinery. I suspect it would > Kevin> be very similar to solib-svr4.c. > > Kevin> With regard to the two patches that have been posted for > Kevin> fixing this problem, I don't think that either one is correct > Kevin> in light of the above definition of "base address". > > It would be interesting to hear from a NetBSD wizard. I'd be happy > with any fix that makes shared libs work in gdb for my platform. > > Part of the reason why I patched gdb rather than ldd.elf_so is so I > could process coredumps from already shipped systems. Then again, > there are few enough of those that this isn't a big consideration. > > paul > >