Apologies if this is the wrong forum, but...
I'm porting Linux to a new architecture, and ran into an issue with
the .rela.dyn entries not being adjusted to compensate for the load_bias
of an ET_DYN shared executable: in particular, this is the ld.so itself that
doesn't get its .rela.dyn entries incremented by +load_bias. This makes
references from _GLOBAL_OFFSET_TABLE_ refer to the old compile-time
vma addresses, which of course causes runtime segfaults (appropriately
enough) with ld.so.
I've poured over binfmt_elf.c to see what it does, but it doesn't appear to
touch any of the sections themselves other than to load them, notably at
p_vaddr + load_bias for .so's.
I tried looking at other architectures to see if I could at least determine what
the proper existing operations are, but came up emtpy. The ET_PLAT_INIT()
macro only updates regisers. This leaves me to assume that the interpreter
itself updates the .rela.dyn entries for shared libs. besides itself, but I can't find
where/how, and how to get it to do so for itself as well.
This only affects ET_DYN type of .so's, because ET_EXEC's don't get a load_bias
and are loaded at the vma for which they were compiled.
Sorry if I sound like a novice...
Thanks for any pointers anyone could provide...
* John Z. Bohach | 2006-05-05 09:44:15 [-0700]:
>I'm porting Linux to a new architecture, and ran into an issue with
>the .rela.dyn entries not being adjusted to compensate for the load_bias
>of an ET_DYN shared executable: in particular, this is the ld.so itself that
>doesn't get its .rela.dyn entries incremented by +load_bias. This makes
>references from _GLOBAL_OFFSET_TABLE_ refer to the old compile-time
>vma addresses, which of course causes runtime segfaults (appropriately
>enough) with ld.so.
This is an issue of the link-editor.
HGN
--
A computer is like an Old Testament god, with a lot of rules and
no mercy. - Joseph Campbell