undefined | Better HN

0 pointsEE84M3i8mo ago0 comments

Shouldn't you use PIE for executables anyway?

0 comments

PIE code is different than PIC. PIE can assume no interposition.

Sorry what do you mean by "symbol interpolation" and "interposition" in this context?

Natively I would assume you can just take the sections out of the shared object and slap them into the executable. They're both position independent so what's the issue?

If PIE allows greater assumptions to be made by the compiler/linker than PIC that sounds great for performance, but doesn't imply PIC code won't work in a PIE context.

accelbred8mo ago

PIC code would work where PIE does, but likely perform worse. In shared libraries, calls to any non-static function can't be assumed to be the same function at runtime, since another library linked or using LD_PRELOAD may also define the symbol. Thus all calls to non-static functions must go through the shared library lookup machinery. This prevents inlining opportunites as well. Functions in an executable can't be overwridden in this manner, and override the symbols in shared libraries. Thus PIE code can have cheaper function calls and freely inline functions.

Its not that you couldn't use the PIC code, but it would be better to just recompile with PIE.

j / k navigate · click thread line to collapse

0 comments

accelbred8mo ago

PIE code is different than PIC. PIE can assume no interposition.

EE84M3iOP8mo ago

Sorry what do you mean by "symbol interpolation" and "interposition" in this context?

Natively I would assume you can just take the sections out of the shared object and slap them into the executable. They're both position independent so what's the issue?

If PIE allows greater assumptions to be made by the compiler/linker than PIC that sounds great for performance, but doesn't imply PIC code won't work in a PIE context.

accelbred8mo ago

Its not that you couldn't use the PIC code, but it would be better to just recompile with PIE.

j / k navigate · click thread line to collapse