[U-Boot] Relocation size penalty calculation

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

Joakim Tjernlund wrote:
> "J. William Campbell" <jwilliamcampbell@comcast.net> wrote on 14/10/2009 17:35:44:
>   
>> Joakim Tjernlund wrote:
>>     
>>> "J. William Campbell" <jwilliamcampbell@comcast.net> wrote on 14/10/2009 01:48:52:
>>>
>>>       
>>>> Joakim Tjernlund wrote:
>>>>
>>>>         
>>>>> Graeme Russ <graeme.russ@gmail.com> wrote on 13/10/2009 22:06:56:
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
>>>>>> <joakim.tjernlund@transmode.se> wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Graeme Russ <graeme.russ@gmail.com> wrote on 13/10/2009 13:21:05:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
>>>>>>>> <joakim.tjernlund@transmode.se> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Graeme Russ <graeme.russ@gmail.com> wrote on 11/10/2009 12:47:19:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> [Massive Snip :)]
>>>>>>>>                 
>
> [Yet another SNIP :)]
>
>   
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> With the following flags
>>>>>>
>>>>>> PLATFORM_RELFLAGS += -fvisibility=hidden
>>>>>> PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
>>>>>> PLATFORM_LDFLAGS += -pic --emit-relocs -Bsymbolic -Bsymbolic-functions
>>>>>>
>>>>>> I get no .got, but a lot of R_386_PC32 and R_386_32 relocations. I think
>>>>>> this might mean I need the symbol table in the binary in order to resolve
>>>>>> them
>>>>>>
>>>>>>
>>>>>>             
>>> BTW, how many relocs do you get compared with -fPIC? I suspect you more
>>> now but hopefully not that many more.
>>>
>>>
>>>       
>>>>> Possibly, but I think you only need to add an offset to all those
>>>>> relocs.
>>>>>
>>>>>
>>>>>           
>>>> Almost right. The relocations specify a symbol value that needs to be
>>>> added to the data in memory to relocate the reference. The symbol values
>>>> involved should be the start of the text section for program references,
>>>> the start of the uninitialized data section for bss references, and the
>>>> start of the data section for initialized data and constants. So there
>>>> are about four symbols whose value you need to keep. Take a look at
>>>> http://refspecs.freestandards.org/elf/elf.pdf (which you have probably
>>>> already looked at) and it tells you what to do with R_386_PC32 ad
>>>> R_386_32 relocations. Hopefully the objcopy with the --strip-unneeded
>>>> will remove all the symbols you don't actually need, but I don't know
>>>> that for sure. Note also that you can change the section flags of a
>>>> section marked noload  to load.
>>>>
>>>>         
>>> Still think you can get away with just ADDING an offset. The image is linked to a
>>> specific address and then you move the whole image to a new address. Therefore
>>> you should be able to read the current address, add offset, write back the
>>>       
>> new address.
>>     
>>> Normally one do what you describe but here we know that the whole img has moved so
>>> we don't have to do calculate the new address from scratch.
>>>
>>>       
>> If the addresses of the bss, text, and data segments change by the same
>> value, I think you are correct. However, if the text and data/bss
>> segments are moved by different offsets, naturally the relocations would
>> be different. One reason to retain this capability would be to allow the
>> u-boot copy to execute in place in NOR flash while re-locating the
>> read-write storage once memory has been sized. Having different
>> relocation factors is not much worse than just one, and it may be just
>> as easy to get working initially as a single relocation constant.
>>     
>
> How do figure that? You need to rewrite the insn to access the moved
> data/bss and they are in flash, did I miss something?
>   
No, I did. You are quite correct, there would be references in flash 
that couldn't be fixed. Sorry about that.

Best Regards,
Bill Campbell
>   
>> FWIW, the "ultimate" solution to minimum relocation size is a
>> post-processing step that creates "several" arrays of relocation offsets
>> as two byte quantities. This reduces the cost of each relocation entry
>> to just a bit more than two bytes (there is a small overhead for array
>> size, MSB values and relocation offset selection.) Naturally, this is
>> much less than the ELF version of the same relocations, because we do
>> not need to retain as much information and ELF doesn't worry about size
>> that much.. This may pacify users for which the flash size of the image
>> is critical, at the expense of an extra link step. Naturally, getting
>> things to work with "standard ELF" is the most important step, and
>> probably enough for most people.
>>     
>
> That would save 2+4 bytes/reloc on REL arches and
> 2+4+4 on RELA(ppc) (provided one can ignore r_addend)
>
> But yes, this is probably too "fancy" for the moment.
>
>   Jocke
>
>
>
>