Re: RFC: ELF prelinker - 0.1.1

[Jakub Jelinek <jakub@redhat.com>]

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