[U-Boot] [PATCH] mpc83xx: Add -fpic relocation support

[Albert ARIBAUD]

Le 12/10/2010 20:11, Joakim Tjernlund a écrit :
>>
>> Le 12/10/2010 19:11, Joakim Tjernlund a écrit :
>>
>>> Figured I should mention that I have added -msingle-pic-base(from ARM)
>>> which
>>> works nicely with -fpic(not sure if -fPIC is possible) and reduces
> size
>>> even more:
>>
>> Since you seem to be following the same path as I did on ARM, I may as
>> well ask: did you try removing -fPIC and -msingle-pic-base from compile
>> options and adding -pie to the link options instead?
>
> looked at it briefly but -pie is really massive. Each access needs
> a reloc entry, even if they access the same data.

OTOH, the accesses are as simple as without reloc, i.e. no indirection 
as GOT introduces. What is the size of the .rel.dyn and .dynsym sections?

>> Link option -pie generates ELF relocation and, on ARM at least, does a
>> better job than GOT reloc, which does not fix handle pointers in
>> initialized data while ELF reloc fixes them.
>
> on ppc -mrelocatable does the job for you and adds fixup relocs.
> It a simple addon that should be fairly easy to add to other archs too.

It does not exist on ARM targets whereas -pie is general.

>> And since ELF reloc does not modify code (it is a linker option), you
>
> ehh, I think you need to reloc directly in the text segment.

I meant that it does not cause the compiler to generate a different 
code, whereas GOT relocation generates a different code, which causes 
the text section to grow.

>> end up with the same size for text+data+rodata. You do have a bigger
>> FLASH image though, because the ELF reloc tables are bigger than the GOT
>
>> table; but you can git rid of them / not copy them to RAM once
> relocated.
>
> I don't think RAM is as much as a problem as flash is.

Indeed in some cases it isnt; but you gain some boot time if you don't 
have to copy the relocation table along with the code.

>> The move from -fPIC to ELF on ARM can be looked for in the elf_reloc
>> branch of the u-boot-arm repo.
>
> Yes, but I believe the ppc way is smaller once -fpic and -msingle-pic-base
> are used(In flash anyway).
> Also, I don't think you will be able to do true PIC in the
> future without PIC code.

Problem is, -fPIC / -fPIE (I tried both) is not really position 
independent either, and requires ugly manual relocation. Besides, for 
the moment, true position independence is not required, although I'd 
like at least the u-boot FLASH startup code to be.

I do understand, though, that ppc and arm may not share a common optimal 
relocation method.

Amicalement,
-- 
Albert.