[U-Boot] [RFC] [PATCH] arm: arm926ejs: use ELF relocations

[J. William Campbell <jwilliamcampbell@comcast.net>]

  On 10/4/2010 5:16 PM, Albert ARIBAUD wrote:
> Le 05/10/2010 01:21, Graeme Russ a ?crit :
>> On Tue, Oct 5, 2010 at 9:57 AM, Albert ARIBAUD<albert.aribaud@free.fr>   wrote:
>>> Le 05/10/2010 00:22, Graeme Russ a ?crit :
>>>> On Tue, Oct 5, 2010 at 9:01 AM, Albert Aribaud<albert.aribaud@free.fr>
>>>>    wrote:
>>> The output from MAKEALL is curiously calculated... If I look at objdumps of
>>> the GOT and ELF binaries, I find that:
>>>
>>> - the GOT .text section is 118960 bytes and the ELF .text section only
>>> 108112. This is due to the fact that GOT relocation requires additional
>>> instruction for GOT indirection whereas ELF relocations work by patching the
>>> code.
>> It would be interesting to compare against the basline non-relocatable
>> version
> I #defined CONFIG_RELOC_FIXUP_WORKS and removed -pie from the ARM
> config.mk. This puts the edminiv2 code in the non-reloc build case, and
> produces identical .text and .data, and almost identical .rodata, as the
> ELF case.
>
>>> - the .rodata section is 22416 for GOT, 22698 for ELF, whereas the .data
>>> section is 2908 for GOT, 2627 for ELF. Some initialized data apparently
>>> moved from non-const ton const for some reason, but basically, initialized
>>> data remains constant.
>>>
>>> - the .bss section remains constant too, 16640 for GOT vs. 16636 for ELF.
>>> I'm not going to track what causes the 4 byte difference. :)
>>>
>>> Many sections are output in the ELF file which do not appear in the GOT
>>> file, such as .interp, .dynamic, .dynstr etc. They probably pollute
>>> MAKEALL's figures.
>> I now discard a few sections:
>>
>> 	/DISCARD/ : { *(.dynstr*) }
>> 	/DISCARD/ : { *(.dynamic*) }
>> 	/DISCARD/ : { *(.plt*) }
>> 	/DISCARD/ : { *(.interp*) }
>> 	/DISCARD/ : { *(.gnu*) }
>>
>> Not that it makes a huge difference - most of these are trivially small
> Thanks. I'll add this to the .lds as a measure of clarity.
>
>>> That's roughly consistent with the numbers I get: about 19 KB of .rel.dyn
>>> plus .dynsym, which we will be able to cut by half if we preprocess it.
>> Which is not copied to RAM, so not as nasty as the .got related increase
> True also. Note that we could probably shrink the table to 1/4 of its
> current size by taking advantage from the fact that the few
> non-program-base-relative relocations it has can easily be converted to
> program-base-relative, and that two consecutive relocations are always
> less than 64 KB away from each other. Of course that moves away from
> using the ELF structures as-is, and requires additional build steps, but
> people with small FLASH devices may want it.
Hi All,
      This may be pushing it in the more general case. ARM has only a 
few relocation types. Other CPU types have more types, and therefore 
still may need a type field. You can certainly get 1/2 in all cases, and 
more if you are willing to get a bit more complex in the preprocessing. 
That said, I think this is best left to later when all CPUs are in the 
relocatable state.
>> I'm also looking at moving the low-level intialisation and relocation code
>> into a seperate section (outside .text) so I even less to relocate to RAM
> As Wolfgang pointed out, there might be issues in that all the code that
> runs in FLASH should be truly PI, which might not be a piece of cake.
> ARM C code, for instance, tends to generate literals which need to be
> relocated if you don't run the code where it was linked for.
True, but the code WILL be running at the address it was linked for. It 
just won't be copied and relocated to the "new" address, as it would 
never be run again anyway. This goal is along the lines of the "two 
stage u-boot" that has been/is being considered, where all execute only 
once code can be concentrated into a segment that is not moved into ram.

Bill Campbell
>> Then I could even compress the relocatable section, but that is just being
>> silly ;)
> :)
>
>> Regards,
>>
>> Graeme
> Amicalement,