Hi thank you very much for your answer!
Did you have a look at the logs of the readelf -r I posted in the other
answer (to you) of mine?
crtbegin.o contained a lot of R_PPC_ADDR16_HA / R_PPC_ADDR16_LO pairs, I
dunno if I can state crtbegin was not compiled -fPIC..
I did not compile gcc myself.. so maybe it is a Debian6 PPC bug.. what
shall I do now? Where to post this problem rather than here?
For my work I tried to solve this way: I created a PowerPC cross
toolchain, where I forced some -fPIC inside gcc sources where it makes
crt stuff..
My new crtbegin.o with readelf -r gives this:
Relocation section '.rela.text' at offset 0x818 contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000000 0000051a R_PPC_REL32 00000000 .got2 + 7ff0
000000d4 0000051a R_PPC_REL32 00000000 .got2 + 7ff0
Relocation section '.rela.got2' at offset 0x830 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000000 00000401 R_PPC_ADDR32 00000000 .bss + 0
00000004 00000401 R_PPC_ADDR32 00000000 .bss + 4
00000008 00001801 R_PPC_ADDR32 00000000 __DTOR_END__ + 0
0000000c 00000801 R_PPC_ADDR32 00000000 .dtors + 0
00000010 00000a01 R_PPC_ADDR32 00000000 .jcr + 0
00000014 00001901 R_PPC_ADDR32 00000000 _Jv_RegisterClasses + 0
Relocation section '.rela.fini' at offset 0x878 contains 1 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000000 00000217 R_PPC_LOCAL24PC 00000000 .text + 4
Relocation section '.rela.init' at offset 0x884 contains 1 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000000 00000217 R_PPC_LOCAL24PC 00000000 .text + d8
There are no more R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs, can I say it is
PIC?
Anyway also the simple PIC "hello world" produced with this crosstool
chain ( Linux kernel version (2.6.35.10 (longterm))
binutils version (2.20.1) gcc version (4.4.3) glibc version (2.9) )
mantains the relocation problem:
powerpc-unknown-linux-gnu-readelf -d bin/ppc-test|grep TEXT
0x00000016 (TEXTREL) 0x0
0x0000001e (FLAGS) TEXTREL
I did the readelf -r to crti.o that is not part of gcc crtstuff but it
is linked to the simple executable at link time, the output is:
Relocation section '.rela.text' at offset 0x468 contains 3 entries:
Offset Info Type Sym.Value Sym. Name + Addend
0000001a 00000306 R_PPC_ADDR16_HA 00000000 .rodata + 0
0000001e 00000304 R_PPC_ADDR16_LO 00000000 .rodata + 0
00000020 0000140a R_PPC_REL24 00000000 __libc_start_main + 0
Relocation section '.rela.rodata' at offset 0x48c contains 4 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000000 00000f01 R_PPC_ADDR32 00000000 _SDA_BASE_ + 0
00000004 00001101 R_PPC_ADDR32 00000000 main + 0
00000008 00001001 R_PPC_ADDR32 00000000 __libc_csu_init + 0
0000000c 00000d01 R_PPC_ADDR32 00000000 __libc_csu_fini + 0
Relocation section '.rela.eh_frame' at offset 0x4bc contains 1 entries:
Offset Info Type Sym.Value Sym. Name + Addend
0000001c 0000021a R_PPC_REL32 00000000 .text + 0
and there is the ugly pair R_PPC_ADDR16_HA/R_PPC_ADDR16_LO, and just
after the R_PPC_REL24 of __libc_start_main that I get as error at runtime..
Can you tell me if this is the NON PIC code causing the mess??
It is produced inside glibc .. I even tried to force -fPIC in the
makefile for that crt?, but crti.o comes up always the same..
Please help me.. other developers told me I can only get such help from
gnu linkers experts!
On 02/22/2011 11:53 PM, Ian Lance Taylor wrote:
You just have to know which relocations are compatible with PIC and
which are not.
Where can I study that? Consider I am seeing for the first time all of
it.. most of all on precious articles like yours :)
Are those not PIC all "R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs" ?
I could be wrong, but I think that those relocs are not PIC.
Is there any official paper where to check it?
They are almost everywhere inside those .o !! What are magic symbols?
How to distinguish them?
There is typically one magic symbol named something like
_GLOBAL_OFFSET_TABLE_.
Thank you.. I met it often while checking the relocs .. so this is a
fine one..
I didn't compile gcc myself.. I am simply using what Debian6 PowerPC
installed during installation.. so if this is bugged, all those who
have installed Debian6 PPC have a bugged one!
What can I do? Is there a way to force gcc to create all PIC code when
installing(or compiling) it?
On GNU/Linux it seems very odd to me that if you use -fPIC on the link
line that you get crtbegin.o rather than crtbeginS.o. Normally
crtbeginS.o is the version compiled with -fPIC.
Anyway to fix the compiler to use the correct one? .. Is it a bug?
Maybe I have to use directly the linker forcing crtbeginS.o?
Thank you very much in advance!
Stefano B.
