CODEWITHSUNDEEP
dynamic-linkinglinkercompiler-constructiondynamic-loading
Vroomfondel
Vroomfondel

Reputation: 2898

Position independent code: what is the difference at compile time?

Reading through the libtool docs I wondered why we need to tell the compiler to produce position independent code. After all, the object file which is produced does not yet know where in address space it will be linked at, so one single object file should be position independent at all times, shouldn't it? And further, to produce shared object libs, wouldn't that simply mean baking together all the object files which make out that lib and possibly setting all relative references which have become "intern" to the baked-together lib, while leaving all other references (absolute and relative) to be filled out later by the linker-loader? Why is this a concern also for the compiler?

Upvotes: 5

Views: 5875

Answers (1)

skush
skush

Reputation: 62

I wondered why we need to tell the compiler to produce position independent code.After all, the object file which is produced does not yet know where in address space it will be linked at, so one single object file should be position independent at all times, shouldn't it?

When you tell your compiler to produce position independent code(PIC), it differs entirely from the compiler which produce non-PIC, mostly regarding function and data access. The reason to use PIC is to avoid buffer overrun or code overwrite which occurs when someone inputs few lines of code into your application address space mostly written in low-level languages like C/C++ because by default C/C++ don't check for bounds.

It uses an indirect method to access the data and functions with the help of a table called "Global Offset Table"(GOT). This GOT is usually located in Special Machine Register. The main benefit to use this table is that the generation of code will be independent of actual load address. At the run time it will update the offsets in the table depending on the current load address of needed libraries.

When the compiler produce an object file (.lo in PIC) it loads the object at random address without modification and even if the load address of an object is fixed for some ABI, it will load the each required libraries at random address.The object file which is produced doesn't know where in address space it will be linked at, well that is exactly PIC wants to do so that no linking address is fixed which might compromise the application security if an attacker finds that address.

And further, to produce shared object libs, wouldn't that simply mean baking together all the object files which make out that lib and possibly setting all relative references which have become "intern" to the baked-together lib, while leaving all other references (absolute and relative) to be filled out later by the linker-loader? Why is this a concern also for the compiler?

In case of shared library, libtool when sees the 'PIC' flag set in the preprocessor it automatically build the object file for shared libraries. They haven't became "intern" because shared libraries could be located anywhere in process memory layout and they are accessed indirectly by some flags set when building.

Wiki: http://en.wikipedia.org/wiki/Position-independent_code

Gentoo: http://wiki.gentoo.org/wiki/Project:Hardened

Upvotes: 3

Related Questions