[U-Boot] Relocation size penalty calculation
J. William Campbell
jwilliamcampbell at comcast.net
Tue Oct 13 18:30:43 CEST 2009
Joakim Tjernlund wrote:
> Graeme Russ <graeme.russ at gmail.com> wrote on 13/10/2009 13:21:05:
>
>> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
>> <joakim.tjernlund at transmode.se> wrote:
>>
>>> Graeme Russ <graeme.russ at gmail.com> wrote on 11/10/2009 12:47:19:
>>>
>> [Massive Snip :)]
>>
>>
>>>> So, all that is left are .dynsym and .dynamic ...
>>>> .dynsym
>>>> - Contains 70 entries (16 bytes each, 1120 bytes)
>>>> - 44 entries mimic those entries in .got which are not relocated
>>>> - 21 entries are the remaining symbols exported from the linker
>>>> script
>>>> - 4 entries are labels defined in inline asm and used in C
>>>>
>>> Try adding proper asm declarations. Look at what gcc
>>> generates for a function/variable and mimic these.
>>>
>> Thanks - Now .dynsym contains only exports from the linker script
>>
> :)
>
>>>> - 1 entry is a NULL entry
>>>>
>>>> .dynamic
>>>> - 88 bytes
>>>> - Array of Elf32_Dyn
>>>> - typedef struct {
>>>> Elf32_Sword d_tag;
>>>> union {
>>>> Elf32_Word d_val;
>>>> Elf32_Addr d_ptr;
>>>> } d_un;
>>>> } Elf32_Dyn;
>>>> - 0x11 entries
>>>> [00] 0x00000010, 0x00000000 DT_SYMBOLIC, (ignored)
>>>> [01] 0x00000004, 0x38059994 DT_HASH, points to .hash
>>>> [02] 0x00000005, 0x380595AB DT_STRTAB, points to .dynstr
>>>> [03] 0x00000006, 0x3805BDCC DT_SYMTAB, points to .dynsym
>>>> [04] 0x0000000A, 0x000003E6 DT_STRSZ, size of .dynstr
>>>> [05] 0x0000000B, 0x00000010 DT_SYMENT, ???
>>>> [06] 0x00000015, 0x00000000 DT_DEBUG, ???
>>>> [07] 0x00000011, 0x3805A8F4 DT_REL, points to .rel.text
>>>> [08] 0x00000012, 0x000014D8 DT_RELSZ, ???
>>>>
>>> How big DT_REL is
>>>
>>>> [09] 0x00000013, 0x00000008 DT_RELENT, ???
>>>>
>>> hmm, cannot remeber :)
>>>
>> How big an entry in DT_REL is
>>
>
> Right, how could I forget :)
>
>>>> [0a] 0x00000016, 0x00000000 DT_TEXTREL, ???
>>>>
>>> Oops, you got text relocations. This is generally a bad thing.
>>> TEXTREL is commonly caused by asm code that arent truly pic so it needs
>>> to modify the .text segment to adjust for relocation.
>>> You should get rid of this one. Look for DT_TEXTREL in .o files to find
>>> the culprit.
>>>
>>>
>> Alas I cannot - The relocations are a result of loading a register with a
>> return address when calling show_boot_progress in the very early stages of
>> initialisation prior to the stack becoming available. The x86 does not
>> allow direct access to the IP so the only way to find the 'current
>> execution address' is to 'call' to the next instruction and pop the return
>> address off the stack
>>
>
> hmm, same as ppc but that in it self should not cause a TEXREL, should it?
> Ahh, the 'call' is absolute, not relative? I guess there is some way around it
> but it is not important ATM I guess.
>
> Evil idea, skip -fpic et. all and add the full reloc procedure
> to relocate by rewriting directly in TEXT segment. Then you save space
> but you need more relocation code. Something like dl_do_reloc from
> uClibc. Wonder how much extra code that would be? Not too much I think.
>
I think this approach will turn out to be a big win. At present, the
problem with just using the relocs is that objcopy is stripping them out
when u-boot.bin is created, as I understand it. It seems this can be
solved by changing the command switches appropriately, like using
--strip-unneeded. In any case, there is some combination of switches
that will preserve the relocation data. The executable code will get
smaller, there will be no .got, and the relocation data will be larger
(than with -fpic). In total size, it probably will be slightly smaller,
but that is a guess. The most important benefit of this approach is that
it will work for all architectures, thereby solving the problem once and
forever! Even if the result is a bit larger, the RAM footprint will be
reduced by the smaller object code size (since the relocation data need
not be copied into ram).Having this approach as an option would be real
nice, since it would always "just work".
Best Regards,
Bill Campbell
>
>> This is not a problem because this is very low-level init that is not
>> called once relocated into RAM - These relocations can be safely ignored
>>
>
>
>>>> [0b] 0x6FFFFFFA, 0x00000236 ???, Entries in .rel.dyn
>>>> [0c] 0x00000000, 0x00000000 DT_NULL, End of Array
>>>> [0d] 0x00000000, 0x00000000 DT_NULL, End of Array
>>>> [0e] 0x00000000, 0x00000000 DT_NULL, End of Array
>>>> [0f] 0x00000000, 0x00000000 DT_NULL, End of Array
>>>> [10] 0x00000000, 0x00000000 DT_NULL, End of Array
>>>>
>>>> I think some more investigation into the need for .dynsym and .dynamic is
>>>> still required...
>>>>
>> .dynsym may still be required if only for accessing the __u_boot_cmd
>> structure. However, I may be able to hack that a little and not create a
>> __u_boot_cmd symbol in the linker script (create some other temporary
>> symbol) and populate __u_boot_cmd with a valid value after relocation. It
>> will look a little weird, but may mean not loading this section into RAM
>>
>
> Why do you need to much around with u_boot_cmd at all? Now that relocation
> works you should be able to drop all that code/linker stuff?
>
>
>> Other than that, .dynsym is now only needed to locate the sections during
>> the relocation phase and can be kept in flash and not copied to RAM
>>
>
> Still occupies space in the *bin image though.
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
More information about the U-Boot
mailing list