Re: RFC: ELF prelinker - 0.1.1

Re: RFC: ELF prelinker - 0.1.1

[James Cownie]

Jakub,

> 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.  */

It seems a pity to have to do so much work in the linker, though,
especially since rewriting DWARF2 will be _very_ unpleasant and
fragile. Since many of the things in DWARF2 are encoded in "LEB128"
format, which basically means they're a byte-string of appropriate
length, _and_ there are inter-object offsets to worry about when you
change the lengths of things in the middle. DWARF2 is _not_ designed
for rewriting. 

When other people (such as SGI) have encountered the need to rewrite
DWARF2 they've chosen to do it by adding additional translation
tables, rather than attempting the DWARF2 modification :-(

Although it requires support in more tools, I would strongly suggest
that the right solution here is to extend the struct link_map to
include a new field for the debugger which is the offset to be applied
to debug information.

Something like this :-

struct link_map
  {
    /* These first few members are part of the protocol with the debugger.
       This is the same format used in SVR4.  */

    ElfW(Addr) l_addr;		/* Base address shared object is loaded at.  */
    char *l_name;		/* Absolute file name object was found in.  */
    ElfW(Dyn) *l_ld;		/* Dynamic section of the shared object.  */
    struct link_map *l_next, *l_prev; /* Chain of loaded objects.  */
    
+   ElfW(Addr) l_debug_relocation;  /* Value to be added to debug entries */
... etc ...

the debugger would then add (l_addr + l_debug_relocation)
to the debug entries.

Somehow you'd need to get this information (which is basically the
preferred base address of the pre-linked library) through to the
dynamic linker. I assume that that's not too hard ?

The advantage of an approach like this is that
the pre-linker doesn't have to relocate the debug information.
So
   It's faster
   It's independent of the debug formats

Making the pre-linker dependent on debug formats is a very bad idea
IMHO...

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

    

Re: RFC: ELF prelinker - 0.1.1

[Jakub Jelinek]

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

Re: RFC: ELF prelinker - 0.1.1

[James Cownie]

> 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.

OK, you'll need to look at (at least) .debug_line and .debug_info.

Good luck !

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

Re: RFC: ELF prelinker - 0.1.1

[Daniel Berlin]

Jakub Jelinek <jakub@redhat.com> writes:

> 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.
> 

As long as you aren't modifying the actual relative offsets of the
DIE's to each other, and to the beginning of the debug_info section,
dwarf2 relocation is easy.  It's only when you have to start dealing
with adjusting the various inter-die references that you run into all
the fun.
DWARF2 rewriting also isn't particularly hard, it's just tedious.

-- 
"In my house on the ceilings I have paintings of the rooms
above...  So I never have to go upstairs.
"-Steven Wright