What code generates gcc without the -fPIC key?

1) I do this:

# gcc -c p1.c

# file p1.o

conclusion:

p1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

relocatable after all means the position-independent code of the object file?

2)

# gcc -c -fPIC p1.c

# file p1.o

conclusion:

 p1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

The conclusion is absolutely the same.

  1. It turns out for .so you can not specify -fPIC ? I apologize for the stupid question.
  2. Is non- -fPIC code position-independent?
  • 3
    And the file size looked? Surely another. From gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html -fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts ... Position-independent code requires special support, .... . For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent -fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts ... Position-independent code requires special support, .... . For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent -fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts ... Position-independent code requires special support, .... . For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent - avp
  • So The short answer to both questions is no . (A relocatable is rather a relocatable (i.e. it can be configured to work from any address, but once configured it may not necessarily be used in other addresses (what is needed for .so))) avp
  • The size is absolutely odiac. > но однажды настроенный он не обязательно м.б. использован в других адресах но однажды настроенный он не обязательно м.б. использован в других адресах can reveal it? - Mike AJ
  • The same function code (say, from a static library) at launch may appear in different programs in different places. When a program is loaded, it is configured according to a specific address. For different launches, these can be different addresses (in this sense, the code is relocatable). In .so, the same code simultaneously appears in different addresses of different processes and it cannot be configured in the same way as the rest of the code is configured when the program is loaded. Therefore, he d. Pic. This is achieved by the fact that all external links in it are indirect and go through GOT (see in Google) - avp
  • For example, here seems an interesting article on this topic - avp

0