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

[Joakim Tjernlund]

Albert ARIBAUD <albert.aribaud at free.fr> wrote on 2010/10/12 22:37:54:
> 
> 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

On ppc that is more work than via the GOT (with -fpic at least). You need
two insn to load the address to a register compared with one to get
it from the GOT.
 
> as GOT introduces. What is the size of the .rel.dyn and .dynsym 
sections?

Don't have that handy.

> 
> >> 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.

I know, I meant you could consider adding it to ARM.

> 
> >> 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.

Not really, it is about the same(2 insn vs. 1 insn and 1 GOT entry).
What builds size is the PIC prologue to load the GOT ptr, but that can
be avoided with -msingle-pic-base

> 
> >> 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.

hmm, can't remember but I think need -pie too(for the fixups). Then you
can test with/without -fpic. If -fpic is similar to ppc -fpic, you 
probably
get smaller code than with -fPIC. Then add -msingle-pic-base too.

> 
> I do understand, though, that ppc and arm may not share a common optimal 

> relocation method.

Yes, but the difference isn't really the arch. It is the -mrelocatable 
flag
that is the big difference.