[U-Boot] ARM relocation, question to Heiko

J. William Campbell jwilliamcampbell at comcast.net
Sun Oct 3 21:26:33 CEST 2010


  On 10/3/2010 11:29 AM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4CA79896.2010606 at emk-elektronik.de>  you wrote:
>> I agree here. _If_ relocation, it should work without hand-adding
>> fixup stuff to all functions using initialized data with pointers.
>> Even Wolfgang forgot to fixup his 2nd level command table in
>> cmd_nvedit.c ;)
> I didn't forget it - at least not in the sensse that I think this is
> something that needs to be done.
>
> This works fine on PPC with relocation, and we should make it work
> the same on other arches.
>
>> And, for space concerns in flash, relocation should always be an
>> option on a board by board basis...
> NAK.
>
>> 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?
> It does. That's the GOT.
I think this is actually a misunderstanding. The purpose of the GOT, at 
least from GCC's point of view, is to hold the absolute addresses of 
private data referenced by shared library code. That is what it was 
invented to do. This is similar to, but not identical with, relocating 
all data references. Initialized data in the library must have a copy 
created (and relocated as necessary if it contains pointers) by the 
runtime linker when the library is initialized in the address space of 
the process using the library. The code in the shared library is -fPIC, 
but it still needs the runtime linker to allocate a copy of the GOT for 
the current user AND to allocate and relocate any data that is required 
for the library that is private to the user. It is that second step 
where we have trouble.

Best Regards,
Bill Campbell
> Best regards,
>
> Wolfgang Denk
>



More information about the U-Boot mailing list