
PIC, PIE and Sanitizers - ingve
https://mropert.github.io/2018/02/02/pic_pie_sanitizers/
======
olliej
Minor nit - inside a given compile object (library, framework, main
executable) with PIC all accesses are performed using a pc relative address
not a table lookup. The performance impact should be no where near 10%. In
fact on arm pc relative addresses are /faster/ as loading an absolute address
requires multiple instructions (if nothing else it hurts the icache).

More seriously the use of a offset table is an implementation detail.

On macOS at least dyld directly patches the majority of cross-object calls and
accesses through stubs, either converting access to a direct absolute address
or a assembly stub that tail calls to the correct place. (Very much a
generalization here :) )

So yes if your code is extremely heavily limited by call and load overhead
from accessing another library you’ll see a real perf impact. But at that
point you should be asking why you’re calling such a lightweight function so
much that the call overhead itself is a problem.

~~~
caf
The 10% quoted was for x86-32 specifically, which does not have PC-relative
addressing modes (x86-64 on the other hand does). In x86-32 PIC code compiled
by GCC for example you will see a lot of calls to __i686.get_pc_thunk.bx to
obtain the PC value in a general purpose register which can then be used for
address generation.

~~~
olliej
I don't really consider 32bit builds to be something that you should be
considering these days -- you should really be building x86-64 at this point.
iOS is 64-bit only, macOS is warning devs about 32bit compiles, I refuse to
believe that windows is still pushing 32bit. I can't imagine building linux
32bit at this point -- seriously, why would you throw away that perf?

------
j1elo
I've been following for a while the CMake issue #14983
([https://gitlab.kitware.com/cmake/cmake/issues/14983](https://gitlab.kitware.com/cmake/cmake/issues/14983)),
which doesn't really get much attention but affects the behavior of the
feature POSITION_INDEPENDENT_CODE. As it is, it's not very reliable because it
misses adding the flag '-pie' to the linker step, which AFAIK should be done
to generate a proper PIE executable.

All this became relevant to me while integrating some Sanitizer CMake modules
in my projects: [https://github.com/arsenm/sanitizers-
cmake](https://github.com/arsenm/sanitizers-cmake) where I opened an issue to
talk about the subject ([https://github.com/arsenm/sanitizers-
cmake/issues/13](https://github.com/arsenm/sanitizers-cmake/issues/13)).

Turns out Qt seems to depend on some obscure / not very well documented
behavior of PIC instead of PIE, so their builds would break if using '-pie',
or at least that's what I understood. In summary I'm amused how such a
seemingly simple operation is getting so much time and complications to
implement properly.

I'm happy to see more conversation about this topic, because as of now it is
still somewhat difficult to grasp and use correctly.

