Albert ARIBAUD <albert.arib...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
