Problem creating PIC executable

Problem creating PIC executable

[Stefano Bonifazi]

Hi all!
  I am reposting the previous problem, as after some investigation the 
problem is more clear:there is some error creating a PIC EXECUTABLE!
Even when creating the simplest code:
int main() {}

compiling with "gcc -fPIC" and then linking with "gcc -Wl,-pie" produces 
non PIC code:

checking all the linked object files (also those added by gcc) with 
"readelf -d myobjectfile | fgrep TEXT" all seem to be PIC as nothing is 
produced by the previous command.
Oddly giving the command "readelf -d mypie_executable | fgrep TEXT" to 
my final 'PIC' output executable I get: "0x00000016 (TEXTREL) 0x0"
Then if I try to load the file with QEMU-USER I get: "error while 
loading shared libraries: R_PPC_REL24 relocation at 0xb31f95a0 for 
symbol `__libc_start_main' out of range" !!!

If I link with "-shared" all is fine and the library is PIC.. Also if I 
create a normal executable, or a normal executable relocated at linker 
time with "-Wl,-Ttext-segment=myaddress" all is fine..
I think the linker goes crazy as I want a PIC executable not a library!

I am creating the binaries using Debian 6 kernel 2.6.32.5 powerpc 
running in a qemu VM, with gcc 4.4.5-8, binutils 2.20.1 eglibc 2.11.2-10

Please help!! I really dunno how to solve it!
Thank you very much in advance!
Stefano B.

Re: Problem creating PIC executable

[Ian Lance Taylor]

Stefano Bonifazi <stefboombastic@gmail.com> writes:

>  I am reposting the previous problem, as after some investigation the
> problem is more clear:there is some error creating a PIC EXECUTABLE!
> Even when creating the simplest code:
> int main() {}
>
> compiling with "gcc -fPIC" and then linking with "gcc -Wl,-pie"
> produces non PIC code:
>
> checking all the linked object files (also those added by gcc) with
> "readelf -d myobjectfile | fgrep TEXT" all seem to be PIC as nothing
> is produced by the previous command.
> Oddly giving the command "readelf -d mypie_executable | fgrep TEXT" to
> my final 'PIC' output executable I get: "0x00000016 (TEXTREL) 0x0"
> Then if I try to load the file with QEMU-USER I get: "error while
> loading shared libraries: R_PPC_REL24 relocation at 0xb31f95a0 for
> symbol `__libc_start_main' out of range" !!!
>
> If I link with "-shared" all is fine and the library is PIC.. Also if
> I create a normal executable, or a normal executable relocated at
> linker time with "-Wl,-Ttext-segment=myaddress" all is fine..
> I think the linker goes crazy as I want a PIC executable not a library!
>
> I am creating the binaries using Debian 6 kernel 2.6.32.5 powerpc
> running in a qemu VM, with gcc 4.4.5-8, binutils 2.20.1 eglibc
> 2.11.2-10

This sounds like you are linking with startup files which were not
compiled with -fPIC.

If you use -v on your link line, you will see the complete set of object
files being used to create your executable.  Look at those executables
and make sure they are compiled with -fPIC.

Note that in some cases the gcc driver will use different startup files
if you use -fPIC on the link line, so make sure you are doing that.

Ian

Re: Problem creating PIC executable

[Stefano Bonifazi]

Hi!
  Thank you very much for your answer!
Are you the same author of this great blog 
http://www.airs.com/blog/archives/category/programming/page/21 ?
If so I could not be luckier! :) There can't be a more expert developer 
for helping me with this problem! :)

I'll post all the output, surely it will tell much more to you than to 
me ...

> RUNNERS_CFLAGS   = -fPIC

> $(RUNNERS_OBJ_DIR)/testppc.o: $(RUNNERS_SRC_DIR)/testppc.c
>     $(CC) -c -o $@ $< $(RUNNERS_CFLAGS)

testppc.c is the simplest c program:
> int main(int argc, char* argv[])
> {
>
> }
I linked it with the following:
> TEST_DEC_BIN = $(BIN_DIR)/ppc-test
>
> test_bin: $(RUNNERS_OBJ_DIR)/testppc.o
>     @echo
>     @echo 'creating test binary'
>     $(CC) -fPIC -Wl,--verbose -Wl,-pie -v -o $(TEST_DEC_BIN) 
> $(RUNNERS_OBJ_DIR)/testppc.o > $(TEST_DEC_BIN).linking.txt

the output is here : 
http://cid-9d0dd0f6c6e22fe8.office.live.com/self.aspx/Documenti/ppc-test.linking.txt
(It is too long for direct posting I think)

the output of the following

>  $(CC) -fPIC -Wl,--verbose -Wl,-pie -v -o $(TEST_DEC_BIN) 
> $(RUNNERS_OBJ_DIR)/testppc.o 2> $(TEST_DEC_BIN).linking2.txt

is here:

http://cid-9d0dd0f6c6e22fe8.office.live.com/self.aspx/Documenti/ppc-test.linking2.txt

Suspecting that there could be some file wrongly linked without fPIC, I 
have tried the following command:

> "readelf -d myobjectfile | fgrep TEXT"


to all object files opened here: 
http://cid-9d0dd0f6c6e22fe8.office.live.com/self.aspx/Documenti/ppc-test.linking.txt
but I could not see anything.. all seemed to be PIC .. I dunno if there 
is any other way for checking if an object file or shared file is really PIC
the same command on the final executable gives:

> 0x00000016 (TEXTREL)   0x0


I am only a student who studies for the first time linkers, loaders on 
articles like Yours (thank you! :) ).. I have got a strict deadline, and 
atm no idea on how to get rid of this problem alone ..
I can post all output from objdump, readelf or whatever can help you in 
understanding what's wrong here..
Thank you very much in advance!
Stefano B.

Re: Problem creating PIC executable

[Ian Lance Taylor]

Stefano Bonifazi <stefboombastic@gmail.com> writes:

> Are you the same author of this great blog
> http://www.airs.com/blog/archives/category/programming/page/21 ?

Yes.

> I have tried the following command:
>
>> "readelf -d myobjectfile | fgrep TEXT"
>
>
> to all object files opened here:
> http://cid-9d0dd0f6c6e22fe8.office.live.com/self.aspx/Documenti/ppc-test.linking.txt
> but I could not see anything.. all seemed to be PIC .. I dunno if
> there is any other way for checking if an object file or shared file
> is really PIC

When linking with -fPIC I would normally expect the gcc driver to use
crtbeginS.o rather than crtbegin.o.  See if crtbegin.o in particular was
compiled without -fPIC.

> the same command on the final executable gives:
>
>> 0x00000016 (TEXTREL)   0x0

It may help to see what relocations are in the text or data segments, to
see why the TEXTREL entry is being added.

Ian

Re: Problem creating PIC executable

[Stefano Bonifazi]

Hi!
On 02/21/2011 08:58 PM, Ian Lance Taylor wrote:
> Stefano Bonifazi<stefboombastic@gmail.com>  writes:
>
>> Are you the same author of this great blog
>> http://www.airs.com/blog/archives/category/programming/page/21 ?
> Yes.
>
Great! :) Thank you for making it public! Really very precious for who 
learns that stuff! :)
> When linking with -fPIC I would normally expect the gcc driver to use
> crtbeginS.o rather than crtbegin.o.  See if crtbegin.o in particular was
> compiled without -fPIC.
>
readelf -d /usr/lib/gcc/powerpc-linux-gnu/4.4.5/crtbegin.o|fgrep TEXT

does not output anything, and as far as I understood it means crtbegin.o 
is PIC

>> the same command on the final executable gives:
>>
>>> 0x00000016 (TEXTREL)   0x0
> It may help to see what relocations are in the text or data segments, to
> see why the TEXTREL entry is being added.
Outputs of
"objdump --dynamic-reloc bin/ppc-test", "objdump --dynamic-syms 
bin/ppc-test", "objdump --syms bin/ppc-test",
"objdump --full-contents bin/ppc-test" and several readelf dumps are here:

<http://cid-9d0dd0f6c6e22fe8.office.live.com/browse.aspx/Pubblic/Developing/master-degree-project>http://cid-9d0dd0f6c6e22fe8.office.live.com/browse.aspx/Public/Developing/master-degree-project

Thank you very much for your help!
Stefano B.

Re: Problem creating PIC executable

[Ian Lance Taylor]

Stefano Bonifazi <stefboombastic@gmail.com> writes:

>> When linking with -fPIC I would normally expect the gcc driver to use
>> crtbeginS.o rather than crtbegin.o.  See if crtbegin.o in particular was
>> compiled without -fPIC.
>>
> readelf -d /usr/lib/gcc/powerpc-linux-gnu/4.4.5/crtbegin.o|fgrep TEXT
>
> does not output anything, and as far as I understood it means
> crtbegin.o is PIC

readelf -d just dumps the .dynamic section.  That is only meaningful for
an object file or a shared library.  It doesn't tell you anything about
a .o file.  The only way to tell whether a .o file was compiled with
-fPIC is to examine the relocations via readelf -r.

>>> the same command on the final executable gives:
>>>
>>>> 0x00000016 (TEXTREL)   0x0
>> It may help to see what relocations are in the text or data segments, to
>> see why the TEXTREL entry is being added.
> Outputs of
> "objdump --dynamic-reloc bin/ppc-test", "objdump --dynamic-syms
> bin/ppc-test", "objdump --syms bin/ppc-test",
> "objdump --full-contents bin/ppc-test" and several readelf dumps are here:
>
> <http://cid-9d0dd0f6c6e22fe8.office.live.com/browse.aspx/Pubblic/Developing/master-degree-project>http://cid-9d0dd0f6c6e22fe8.office.live.com/browse.aspx/Public/Developing/master-degree-project

I see a lot of R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs in the dynamic
relocs.  If you use -fPIC you should not see those relocs, except
perhaps against some magic symbols which is not what is happening here.
So I suspect that those relocs are coming from crtbegin.o.  If you run
readelf -r on crtbegin.o, and you see those relocs, that will suggest
that crtbegin.o was not compiled with -fPIC.

Ian

Re: Problem creating PIC executable

[Stefano Bonifazi]

Thank you very much for Your answer!

On 02/22/2011 02:45 AM, Ian Lance Taylor wrote:
>
> readelf -d just dumps the .dynamic section.  That is only meaningful for
> an object file or a shared library.  It doesn't tell you anything about
> a .o file.  The only way to tell whether a .o file was compiled with
> -fPIC is to examine the relocations via readelf -r.
>
I thought an object file is a .o file ..

I've collected the outputs of readelf -r for all the files listed in the 
linking process and I've uploaded them here:

http://cid-9d0dd0f6c6e22fe8.office.live.com/browse.aspx/Public/Developing/master-degree-project/Logs?uc=5

Anyway I am very confused .. You know I am a beginner with these 
things.. if I reference, let's say a function that is implemented on 
another module from a c file, then it should contain some sort of 
"relocation information" needed for resolving at link time the symbol.. 
so how can I distinguish in those relocs listings this normal 
informations from what instead is caused by not PIC compilation?
Are those not PIC all "R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs" ?
They are almost everywhere inside those .o !! What are magic symbols? 
How to distinguish them?
I think I'll better return on your blog about linkers .. I have got a so 
strict deadline that I could not study them properly..
Can you say for sure that one(or more) of those files is not PIC as it 
should from my listings?
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?

Thank you very much!
Stefano B.

Re: Problem creating PIC executable

[Ian Lance Taylor]

Stefano Bonifazi <stefboombastic@gmail.com> writes:

> On 02/22/2011 02:45 AM, Ian Lance Taylor wrote:
>>
>> readelf -d just dumps the .dynamic section.  That is only meaningful for
>> an object file or a shared library.  It doesn't tell you anything about
>> a .o file.  The only way to tell whether a .o file was compiled with
>> -fPIC is to examine the relocations via readelf -r.
>>
> I thought an object file is a .o file ..

Yes, they are the same thing.

> Anyway I am very confused .. You know I am a beginner with these
> things.. if I reference, let's say a function that is implemented on
> another module from a c file, then it should contain some sort of
> "relocation information" needed for resolving at link time the
> symbol.. so how can I distinguish in those relocs listings this normal
> informations from what instead is caused by not PIC compilation?

You just have to know which relocations are compatible with PIC and
which are not.

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

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

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

Ian

Re: Problem creating PIC executable

[Stefano Bonifazi]

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.

Re: Problem creating PIC executable

[Ian Lance Taylor]

Stefano Bonifazi <stefboombastic@gmail.com> writes:

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

It was not compiled with -fPIC.

I've been trying to say that gcc should be linking with crtbeginS.o if
you use -fPIC on the link line.  That that is not happening is almost
certainly a bug somewhere.

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

I would report it to the maintainer of the Debian PPC package.

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

Yes, that was compiled with -fPIC.

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

Yes, that was also compiled without -fPIC, and that is apparently the
next thing you will have to fix.

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

Normally crti.o is always compiled with -fPIC, so again I don't know why
that has not happened on your system.

I don't know anything about Debian PPC, but it seems like something is
wrong with the way it was built.

Ian