From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27332 invoked by alias); 10 Feb 2003 21:45:09 -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 27325 invoked from network); 10 Feb 2003 21:45:09 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by 172.16.49.205 with SMTP; 10 Feb 2003 21:45:09 -0000 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h1ALj9626316 for ; Mon, 10 Feb 2003 16:45:09 -0500 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h1ALj8r26304; Mon, 10 Feb 2003 16:45:08 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h1ALj7l32134; Mon, 10 Feb 2003 16:45:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15944.11122.815000.978417@gargle.gargle.HOWL> Date: Mon, 10 Feb 2003 21:45:00 -0000 From: Paul Koning To: kevinb@redhat.com Cc: kewarken@qnx.com, gdb@sources.redhat.com, peterv@qnx.com, cburgess@qnx.com Subject: Re: relocation of shared libs not based at 0 References: <032c01c2a60a$2368a6e0$0202040a@catdog> <1021218002802.ZM4459@localhost.localdomain> <15871.50596.942339.277490@pkoning.akdesign.com> <08ab01c2b760$2e6612a0$0202040a@catdog> <15937.26809.680000.225947@gargle.gargle.HOWL> <1030205191053.ZM3334@localhost.localdomain> X-SW-Source: 2003-02/txt/msg00184.txt.bz2 >>>>> "Kevin" == Kevin Buettner writes: Kevin> On Feb 5, 2:40pm, Paul Koning wrote: >> I'm resurrecting this thread to bring up a problem that's closely >> related. >> >> On mips-netbsd, even after fixing the relocation problem (e.g., by >> the patch I proposed earlier) gdb still has problems. >> Specifically, it computes the wrong address for data within the >> shared library.... >> >> When the library is loaded, text and data are relocated separately >> since they are two separate mmap regions. So the relocation bias >> is different for the two. The i386 case works because the symbols >> are correctly marked as to which region they belong to (text, >> data, bss). But the mips case doesn't have that, so all symbol >> relocation is done as if the symbols were text. The data and bss >> offsets are fine as file offsets, but because the parts are mapped >> separately they are NOT valid as memory address offsets. >> >> I'm wondering what the right way to fix this is. Two ways come to >> mind: >> >> 1. Fix ld so it puts the right section designations on the >> symbols, just as in the i386 case. >> >> 2. Hack gdb so it looks at the section headers in the shared >> library file, to extract the start and length of the three >> regions. Use that to identify the *ABS* symbols (i.e., p is bss >> since it's within the vaddr range of the bss section in the >> section headers), and then figure the correct relocation from >> that. >> >> I can do (2), and that has the advantage of working with existing >> binaries, but it seems ugly. (1) sounds right. There are two >> issues there, though. One is that I don't know ld. The other is >> that I'm guessing there must be SOME reason why *ABS* is used for >> the mips case, though I can't imagine any reason. Kevin> (1) sounds right to me too, though I share your concern that Kevin> there may be some reason that ABS must be used the way it is Kevin> for mips. I think you ought to ask about this on the binutils Kevin> list... Kevin> If you have to do (2), I strongly encourage you to create a Kevin> new solib backend for it. I was looking at solib-svr4.c and found this interesting comment (in svr4_relocate_main_executable): /* It is necessary to relocate the objfile. The amount to relocate by is simply the address at which we are stopped minus the starting address from the executable. We relocate all of the sections by the same amount. This behavior is mandated by recent editions of the System V ABI. According to the System V Application Binary Interface, Edition 4.1, page 5-5: ... Though the system chooses virtual addresses for individual processes, it maintains the segments' relative positions. Because position-independent code uses relative addressesing 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. One use of the base address is to relocate the memory image of the program during dynamic linking. The same language also appears in Edition 4.0 of the System V ABI and is left unspecified in some of the earlier editions. */ So if I read that right, it sounds like the NetBSD practice of doing separate mappings for the text, data, and bss sections (rather than leaving them at the same relative offset they were in the library file) violates the SVR4 spec. Very interesting. I'm not sure what to make of this. It doesn't feel like a bug; the NetBSD behavior certainly makes sense. That suggests at least two other approaches: 3. Change NetBSD ld.elf_so to do what the ABI spec requires, which means just one mapped region rather than three. 4. Change the linker so ld.elf_so can still use three regions, i.e., align the start of each region on a page boundary. Yikes. Now what? I may end up just doing (2) for the sake of in-house expedience, and hope someone more skilled in the art will tackle the "right" solution. paul