[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