This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: ELF prelinker - 0.1.1
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: RFC: ELF prelinker - 0.1.1
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Thu, 05 Jul 2001 11:42:43 -0400
- Cc: James Cownie <jcownie at etnus dot com>, libc-alpha at sources dot redhat dot com,binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- References: <20010705125600.Q737@sunsite.ms.mff.cuni.cz><15I7Lu-0j2-00@etnus.com><20010705080214.O32061@devserv.devel.redhat.com>
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