[U-Boot] ARM relocation, question to Heiko

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 04/10/2010 17:28, J. William Campbell a ?crit :
> On 10/4/2010 3:13 AM, Wolfgang Denk wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4CA999EE.5030309@free.fr> you wrote:
>>> Note however that linking for base address 0 is not mandatory for
>>> achieving true position independence. What is required is that the code
>>> which runs from power-up until relocation be able to run anywhere, i.e.,
>>> this code should not require any relocation fixup. That can be achieved
>>> on ARM by using only relative branches and accessing data only relative
>>> to pc (e.g. literals) or truly absolute (e.g. HW registers etc).
>> That means you need to build all of U-Boot that way, because
>> significant parts of the code already run before relocation
>> (including all clocks and timers setup, console setup, printf and all
>> routines these pull in).
>>
> Yes, I think Wolfgang is correct. This is not going to be easy to do in
> general. To run anywhere, the code must be true Position Independent
> code. If you intend to use any C code in the initialization, this will
> result in needing -fPIC for at least that code. I am not sure you can
> mix -fPIC and non -fPIC code in the same link, but I expect not. I am a
> bit surprised that it is possible to get even the initialization code to
> be Position Independent, but it appears that on at least some PPC it is
> possible/has been done.

I'm not entirely sure about -fPIC, but it is possible indeed that true 
position independence might need it. For the moment, I'll settle for ELF 
relocatable. :)

> On a related topic, I did find some information on the -mrelocatable
> history. Take a look at
> http://www.mail-archive.com/gcc at gcc.gnu.org/msg02528.html.
> If you read both thread entries, it explains -mrelocatable as more or
> less the post-processor that re-formats the ELF relocation information
> into a smaller format and puts it in the text as another segment. What
> Albert is doing now, and Graeme did before, is the first option,
> creating a loader that understands ELF. This has the advantage that it
> will work on all architectures. However, once this understanding is in
> place, it would be easy to write a small post-processing program that
> would reduce the size of the relocation entries, much like -mrelocatable
> does. This may or may not be necessary, but it is certainly possible.
>
> Best Regards,
> Bill Campbell

Thanks Bill. I'll look into it once I get the current issues resolved; 
however it seems GOT-related, and -pie is not GOT-based -- and unlike 
GOT, -pie handles pointers in data, for instance, removing the need for 
manual fixups.

Amicalement,
-- 
Albert.