Albert ARIBAUD albert.aribaud@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.