build: PIC-ify the dynamic SDK overlay #15801
Conversation
|
@jrose-apple perhaps we should have a CI build that builds the shared SDK overlay for Linux? |
|
@swift-ci please test |
|
I'm pretty sure that's how all our builds work on Linux. Why would we do this here and not in the Clang importer in general? Do we need to support non-PIC at all? |
|
No, we can't and shouldn't need to support non-PIC. |
|
@jrose-apple hmm, doing that in the clang importer seems reasonable. Not supporting PIC can technically be beneficial. The non-PIC CodeGen would avoid the GOT/PLT which can be a significant cost if you are calling functions across modules often. But, always building PIC means that it would work everywhere. |
|
The GOT and PLT are only strictly necessary for cross-dynamic library calls, in which case they're unavoidable. Within a binary, they're unnecessary and can be avoided if the symbols are known to be in the same binary. The overhead of PIC for code within a binary was more significant for platforms like 32-bit i386 that didn't support PC-relative data addressing, but for x86_64 the cost of PIC is much smaller. Disabling PIC is not supported for dynamic libraries on Linux, and disabling it for executables means they can't support ASLR. |
|
Cool, then let's just throw this in the importer and be done with it. :-) |
compnerd
force-pushed
the
pics
branch
2 times, most recently
from
6b52460 to
2a86b36
Compare
|
@swift-ci please test |
|
Is there a way to write a test case for this? |
The dynamic SDK overlay needs to be built with -fPIC. Ensure that the clang importer is marking the external globals appropriately. This was caught by building the swiftGlibc SDK overlay component in a dynamic configuration. Failure to do so will create RIP-relative references on x86_64 which may overflow at runtime.
|
@jrose-apple to ensure that the flag is there, or something else? |
|
I guess that we don't generate code that references Clang-imported declarations incorrectly. |
|
Yeah, I didn't see much that a test would've caught really. But, if you have an idea of something that would be useful, I'd be happy to address that. |
|
Ah, right, because none of this shows up until linking, and then the actual thing you'd check would have to be disassembly, which is pretty platform-specific. All right, never mind. |
|
@swift-ci please test and merge |
|
Build failed |
|
Build failed |
|
While it'd be nice to have a test, I think that failure to build things as PIC will manifest itself incidentally fairly reliably when we try to link a dynamic library with non-PIC code in it. |
The dynamic SDK overlay needs to be built with -fPIC. Ensure that the
clang importer is marking the external globals appropriately. This was
caught by building the swiftGlibc SDK overlay component in a dynamic
configuration. Failure to do so will create RIP-relative references on
x86_64 which may overflow at runtime.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.