From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22647 invoked by alias); 12 Feb 2003 18:37:48 -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 22618 invoked from network); 12 Feb 2003 18:37:47 -0000 Received: from unknown (HELO nimbus.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 12 Feb 2003 18:37:47 -0000 Received: by nimbus with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 13:37:47 -0500 Message-ID: <1578FF984ABAD411AFA5000102C4BB5B034980EA@nimbus> From: Peter van der Veen To: 'Kevin Buettner' , 'Paul Koning' Cc: Kris Warkentin , "'gdb@sources.redhat.com'" , Peter van der Veen , Colin Burgess Subject: RE: relocation of shared libs not based at 0 Date: Wed, 12 Feb 2003 18:37:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2003-02/txt/msg00202.txt.bz2 > From: Kevin Buettner [mailto:kevinb@redhat.com] > > 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'm not sure if this is what you are referring to, but here is what I have observed. The System V ABI makes statements about base address, and relative to that document base address is consistent. But the base address in the l_addr field in link.h is not the same base address that the system V abi is talking about. I think problems started when someone saw these both referred to as "base address" and assumed they both where the same value. l_addr is the address of the library at load time, but not the same value as the base address in the ABI. I would think your comment that the NETBSD behaviour does not feel like a bug is correct. I think the linux ld.so may treat both base addresses as being the same thing, but I am not sure. > > 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.)