From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10823 invoked by alias); 12 Feb 2003 18:06:18 -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 10816 invoked from network); 12 Feb 2003 18:06:17 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 12 Feb 2003 18:06:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1CI6Hf11821 for ; Wed, 12 Feb 2003 13:06:17 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1CI6Ha20471; Wed, 12 Feb 2003 13:06:17 -0500 Received: from localhost.localdomain (vpn50-26.rdu.redhat.com [172.16.50.26]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1CI6Gs11358; Wed, 12 Feb 2003 13:06:16 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1CI69r11325; Wed, 12 Feb 2003 11:06:09 -0700 Date: Wed, 12 Feb 2003 18:06:00 -0000 From: Kevin Buettner Message-Id: <1030212180609.ZM11324@localhost.localdomain> In-Reply-To: Paul Koning "Re: relocation of shared libs not based at 0" (Feb 10, 5:45pm) 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> <15944.11122.815000.978417@gargle.gargle.HOWL> To: Paul Koning , kevinb@redhat.com Subject: Re: relocation of shared libs not based at 0 Cc: kewarken@qnx.com, gdb@sources.redhat.com, peterv@qnx.com, cburgess@qnx.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00200.txt.bz2 On Feb 10, 5:45pm, Paul Koning wrote: > >> 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. Yes, upon rereading that comment, I agree with you. If you haven't already done so, you may want to take a look at the ABI yourself to make sure that the comment quotes the ABI correctly and to understand the context of the quote. I wrote that comment, and I believe it to be accurate with sufficient context, but it doesn't hurt for someone else to double check. You should also take a look at the processor specific supplement. I don't think that the processor supplement will override the text quoted above from the generic part of the specification, but this possibility should be checked before declaring the NetBSD implementation wrong. > 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. If NetBSD wants to comply with the System V ABI (and if I've interpreted the text of the ABI correctly), then the dynamic linker needs fixing. I can understand wanting to do (2) for expediency's sake. If you do so, please create a new solib backend. Basically, this will consist of making a copy of solib-svr4.c and hacking on it 'til it works as desired. (Some small configury changes will also be needed.) Kevin