23

The test is on Ubuntu 12.04 64-bit. x86 architecture.

I am confused about the concept Position Independent Executable (PIE) and Position Independent code (PIC), and I guess they are not orthogonal.

Here is my quick experiment.

gcc -fPIC -pie quickSort.c -o a_pie.out
gcc -fPIC      quickSort.c -o a_pic.out
gcc                           a.out

objdump -Dr -j .text a.out > a1.temp
objdump -Dr -j .text a_pic.out > a2.temp
objdump -Dr -j .text a_pie.out > a3.temp

And I have the following findings.

A. a.out contains some PIC code, but only resists in the libc prologue and epilogue functions, as shown in below: 

4004d0:       48 83 3d 70 09 20 00    cmpq   $0x0,0x200970(%rip)        # 600e48 <__JCR_END__>

In the assembly instructions of my simple quicksort program, I didn't find any PIC instructions.

B. a_pic.out contains PIC code, and I didn't find any non-PIC instructions... In the instructions of my quicksort program, all the global data are accessed by PIC instructions like this:

  40053b:       48 8d 05 ea 02 00 00    lea    0x2ea(%rip),%rax        # 40082c <_IO_stdin_used+0x4>

C. a_pie.out contains syntax-identical instructions comparing with a_pic.out. However, the memory addresses of a_pie.out's .text section range from 0x630 to 0xa57, while the same section of a_pic.out ranges from 0x400410 to 0x400817.

Could anyone give me some explanations of these phenomenons? Especially the finding C. Again, I am really confused about PIE vs. PIC, and have no idea how to explain the finding C..

Perl99
  • 73
  • 5
lllllllllllll
  • 8,519
  • 9
  • 45
  • 80
  • 3
    Basically `PIE` is intended for executables and `PIC` for shared libraries. It doesn't make much sense to examine `PIC` executables. Also note that `gcc` invokes the linker accordingly. – Jester Jan 23 '15 at 22:28
  • `-fPIC -pie` /facepalm. You should have used the `-fPIE` code-gen option, not `-fPIC`. `-pie` is a linker option that controls what kind of executable the code is actually put into. (`-pie` alone would fail because it's incompatible with 32-bit absolute addressing). See also [32-bit absolute addresses no longer allowed in x86-64 Linux?](//stackoverflow.com/q/43367427) for more about PIE executables vs. non-PIE. (And note that most distros build GCC with `-fPIE -pie` being the default). – Peter Cordes Nov 04 '19 at 03:33

1 Answers1

24

I am confused about the concept Position Independent Executable (PIE) and Position Independent code (PIC), and I guess they are not orthogonal.

The only real difference between PIE and PIC is that you are allowed to interpose symbols in PIC, but not in PIE. Except for that, they are pretty much equivalent.

You can read about symbol interposition here.

C. a_pie.out contains syntax-identical instructions comparing with a_pic.out. However, the memory addresses of a_pie.out's .text section range from 0x630 to 0xa57, while the same section of a_pic.out ranges from 0x400410 to 0x400817.

The PIE binary is linked just as a shared library, and so its default load address (the .p_vaddr of the first LOAD segment) is zero. The expectation is that something will relocate this binary away from zero page, and load it at some random address.

On the other hand, a non-PIE executable is always loaded at its linked-at address. On Linux, the default address for x86_64 binaries is 0x400000, and so the .text ends up not far from there.

renevague3
  • 3
  • 2
Employed Russian
  • 199,314
  • 34
  • 295
  • 362