Haavard Skinnemoen wrote:
On Fri, 25 Jul 2008 19:28:48 +0200 kenneth johansson kenneth@southpole.se wrote:
I was afraid that what was needed was more or less a complete linker but it looks like if one generate the dynamic reloc table a much simpler linker(relocation function) is needed. Still probably a lot more complex than the GOT and fixup code that is just a loop over a table. We may need a case also ;-)
First of all, you are correct that "fully linked" executables contain no relocation information unless the user does something like --emit-relocs. I was wrong about that.
Hmm...looks like linking with -pie (or --pic-executable) does something vaguely resembling the trick. But I don't know what vintage of ld you need for this to be available and actually work...
hskinnemoen@siona:~/work/u-boot/master$ avr32-linux-readelf -d u-boot
Dynamic section at offset 0x1b8f0 contains 12 entries: Tag Type Name/Value 0x00000004 (HASH) 0x182ac 0x00000005 (STRTAB) 0x18260 0x00000006 (SYMTAB) 0x18150 0x0000000a (STRSZ) 74 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000003 (PLTGOT) 0x1ae70 0x70000001 (Processor Specific: 70000001) 0xe6c 0x00000015 (DEBUG) 0x0 0x00000007 (RELA) 0x1833c 0x00000008 (RELASZ) 6996 (bytes) 0x00000009 (RELAENT) 12 (bytes) 0x00000000 (NULL) 0x0
The dynamic relocation section became surprisingly large. I wonder if we actually manage to manually relocate all those buggers...I checked a couple of them and in both cases it looked like something that needed to be relocated, but I couldn't find any code that actually did it.
One example from common/cmd_itest.c:
op_tbl_t op_table [] = { { "-lt", LT }, { "<" , LT }, { "-gt", GT }, { ">" , GT }, { "-eq", EQ }, { "==" , EQ }, { "-ne", NE }, { "!=" , NE }, { "<>" , NE }, { "-ge", GE }, { ">=" , GE }, { "-le", LE }, { "<=" , LE }, };
Does this really work without any relocation? Or is it being relocated and I'm just too blind to see it?
Is your u-boot built with -fPIC on all the C compiles? If so, op_table references may work without any actual relocation if the distance from the code segment to the segment containing op_table is not changed when u-boot is "relocated" to the new address. If you look at the assembly code for op_table being used, it may be done via an offset from the start of the code + a register pointing to the start of the code. The offset will not change when the code is moved, and the register will contain the correct start of code address, so it works. If it is not -fPIC, and it is not being executed at the address for which it was linked, I have no idea how it would work without a "loader" relocating all the references. There are "only" 583 relocation entries specified!
I think you are correct that the --pic-executable switch is the "generic" way to get the relocation addresses. I expect it is much better supported than the PPC specific compiler switches, because ld needs to have the relocation data on all platforms. The only additional requirement is for ld to actually output this data. It seems pretty likely that this is implemented on all platforms, because at least a subset of it is required for shared libraries and dynamically linked executables.
Best Regards, Bill Campbell
The symbol tables can probably be made smaller with some careful ldscript tweaking.
Haavard
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users