From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Jelinek To: James Cownie Cc: libc-alpha@sources.redhat.com, binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: RFC: ELF prelinker - 0.1.1 Date: Thu, 05 Jul 2001 05:02:00 -0000 Message-id: <20010705080214.O32061@devserv.devel.redhat.com> References: <20010705125600.Q737@sunsite.ms.mff.cuni.cz> <15I7Lu-0j2-00@etnus.com> X-SW-Source: 2001-07/msg00040.html On Thu, Jul 05, 2001 at 12:31:22PM +0100, James Cownie wrote: > > I have to. Debugger relocates them too, but debugger relocates them > > by adding link_map->l_addr, which is load address, not base address. > > Load address is the difference between actual virtual addresses in > > library and virtual addresses stored in the library. > > Ahh, so the point is that l_addr is zero for a pre-linked library in > the good case, or the offset of where you have to place the pre-linked > library from where you pre-linked it to in the bad case. > > So you are right, the debugger won't do any relocation for you (well, > it will, but adding zero doesn't achieve anything !). > > Previously (when shared libraries were all linked as though they would > be loaded at zero), l_addr _was_ the base address of the library. > > After all, l_addr is declared like this :- > ElfW(Addr) l_addr; /* Base address shared object is loaded at. */ But glibc's private link.h has this comment for a long time: /* Start and finish of memory map for this object. l_map_start need not be the same as l_addr. */ ElfW(Addr) l_map_start, l_map_end; Anyway, from my initial look at DWARF2, DWARF2 relocation will be fairly easy as that format is nicely designed. Nothing in LEB128 format needs to be relocated, essentially: - nothing in .debug_abbrev - don't have to care about .eh_frame, since it is SHF_ALLOC and has its REL{,A} section - no addresses which need relocation, can be in LEB128 format (how would static linker work in that case?), there is nothing like R_IA64_ULEB128, is it? From my current brief look at DWARF2, DW_FORM_addr format attributes will have to be adjusted, plus DW_OP_addr's, will need to check some more if I haven't missed something - will need to figure out what to do about the rest of .debug_* sections - but the prelinker will certainly just bail out if it finds a debug section or its format which it does not recognize. Jakub