[U-Boot] ARM relocation, question to Heiko

[Graeme Russ]

On 03/10/10 18:10, Albert ARIBAUD wrote:
> Le 03/10/2010 01:07, Graeme Russ a écrit :
>> On 03/10/10 08:09, Albert ARIBAUD wrote:
>>> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>>>
>>>> And as an idea, if position independent code is used, only pointers
>>>> in initialized data need adjustment. Cannot the linker emit a table
>>>> of addresses that need fixing?
>>>
>>> IIU Bill C, yes the linker can emit the information and the startup code
>>> could use this information instead of relying on hand-provided info; the
>>> linker file probably needs to be modified in order to provide such info.
>>> I intend to look into this, but feel free to do too.
>>
>> As mentioned previously, I have already done this for x86. The linker
>> flags
>> used are -pic and --emit-relocs. The linker produces a section named
>> rel.dyn which needs to be processed but not loaded into RAM. rel.dyn
>> contains a simple list of address (within .text, .data, .rodata etc) each
>> of which need a simple adjustment equal to the relocation offset.
> 
> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
> for relocation. You seem to imply it actually is... In my experience,
> -fPIC and-fPIE do increase code by adding GOT relocation to symbols that
> need fixing, so they would indeed be redundant to any other relocation
> mechanism -- I just did some test with basic code and this seems to
> confirm, no -fPIx is needed to get relocation the way you do on ARM.
> 

Just to clarify -fpic is a compiler option, -pic is a linker option. x86
has no compile time relocation options (therefore no referencing .got etc).
Using the link time pic option produces the relocation data table
(.rel.dyn) which must be pre-processed before execution can begin at the
relocated address

Cheers,

Graeme