* Re: RFC: ELF prelinker - 0.1.1 [not found] <20010705125600.Q737@sunsite.ms.mff.cuni.cz> @ 2001-07-05 4:31 ` James Cownie 2001-07-05 5:02 ` Jakub Jelinek 0 siblings, 1 reply; 4+ messages in thread From: James Cownie @ 2001-07-05 4:31 UTC (permalink / raw) To: Jakub Jelinek; +Cc: libc-alpha, binutils, gdb 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: ELF prelinker - 0.1.1 2001-07-05 4:31 ` RFC: ELF prelinker - 0.1.1 James Cownie @ 2001-07-05 5:02 ` Jakub Jelinek 2001-07-05 6:08 ` James Cownie 2001-07-05 8:42 ` Daniel Berlin 0 siblings, 2 replies; 4+ messages in thread From: Jakub Jelinek @ 2001-07-05 5:02 UTC (permalink / raw) To: James Cownie; +Cc: libc-alpha, binutils, gdb 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: ELF prelinker - 0.1.1 2001-07-05 5:02 ` Jakub Jelinek @ 2001-07-05 6:08 ` James Cownie 2001-07-05 8:42 ` Daniel Berlin 1 sibling, 0 replies; 4+ messages in thread From: James Cownie @ 2001-07-05 6:08 UTC (permalink / raw) To: Jakub Jelinek; +Cc: libc-alpha, binutils, gdb > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: ELF prelinker - 0.1.1 2001-07-05 5:02 ` Jakub Jelinek 2001-07-05 6:08 ` James Cownie @ 2001-07-05 8:42 ` Daniel Berlin 1 sibling, 0 replies; 4+ messages in thread From: Daniel Berlin @ 2001-07-05 8:42 UTC (permalink / raw) To: Jakub Jelinek; +Cc: James Cownie, libc-alpha, binutils, gdb 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-07-05 8:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20010705125600.Q737@sunsite.ms.mff.cuni.cz>
2001-07-05 4:31 ` RFC: ELF prelinker - 0.1.1 James Cownie
2001-07-05 5:02 ` Jakub Jelinek
2001-07-05 6:08 ` James Cownie
2001-07-05 8:42 ` Daniel Berlin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox