PIC, PIE and Sanitizers | Hacker News Reader

PIC, PIE and Sanitizers

mropert.github.io

25 pointsingve6 comments

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.

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.

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?

Note that only non-exported functions can be called directly. If you call a exported function, it has to go through the GOT to support redirection (LD_PRELOAD). There's a flag to disable that.

  -Bsymbolic-functions

I've been following for a while the CMake issue #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 where I opened an issue to talk about the subject (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.

Reply on news.ycombinator.com