Support PIC and PIE for AArch64, RISC-V and x86-64 #551
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for generating position-independent executables (PIE), Position-independent code (PIC) and shared libraries for AArch64, RISC-V and x86-64 (Linux and macOS; no Cygwin at this point).
For AArch64 and x86-64, it builds on the existing macOS support, which requires all symbols not defined in the current compilation unit to be accessed via the GOT, not with an absolute address. We just need to adjust the criterion used to choose between "access via the GOT or the PLT" and "access at fixed addresses":
The RISC-V port was adapted to use the same per-symbol approach. It already had some support for PIC code, but it was less precise (all symbols were using the GOT), turned off, and slightly buggy.
The other CompCert target platforms (ARM, PowerPC, x86-32) lack PC-relative addressing, making it significantly harder to generate PIC code. We will stick with statically-linked code for the time being.
PIE was already the default for macOS. This PR makes it the default for Linux and BSD, since OpenBSD and most Linux distributions are PIE by default. This can be turned off with
-fno-pie
at code generation time and-no-pie
at link time.I didn't try to quantify the performance degradation caused by PIE. It's probably low, as it only affects accesses to global variables defined in another compilation unit.