-
Notifications
You must be signed in to change notification settings - Fork 74
Add pie relocation-model #461
Copy link
Copy link
Closed
Labels
T-compilerAdd this label so rfcbot knows to poll the compiler teamAdd this label so rfcbot knows to poll the compiler teammajor-changeA proposal to make a major change to rustcA proposal to make a major change to rustcmajor-change-acceptedA major change proposal that was acceptedA major change proposal that was accepted
Metadata
Metadata
Assignees
Labels
T-compilerAdd this label so rfcbot knows to poll the compiler teamAdd this label so rfcbot knows to poll the compiler teammajor-changeA proposal to make a major change to rustcA proposal to make a major change to rustcmajor-change-acceptedA major change proposal that was acceptedA major change proposal that was accepted
Type
Fields
Give feedbackNo fields configured for issues without a type.
Proposal
We currently compile crates (
--crate-type=rlib) inrelocation-model=picas PIC. When rustc knows the code will not be linked into a shared library (when it builds a binary crate) it uses PIE.This is a reasonable default, PIC objects are relocatable and can be used for both executables and shared libraries. PIE objects are also relocatable, but their code can be faster than with PIC. The downside is that they cannot be used for shared libraries.
We would like introduce a way to build crates as PIE in performance-critical scenarios where we need relocatable code and we know we won't need to produce shared libraries.
We propose to add
pieas anotherrelocation-modelvalue. Prototype PR: rust-lang/rust#88820.Alternatives considered
LLVM doesn't have
pieas a relocation-model value, instead it has a concept ofPIC levelandPIE level. If we wanted to mirror the LLVM design, we could add a new rustc option for controlling PIE whenrelocation-model=picis used.We think using
pierelocation-model value is more understandable both from the user perspective and from the implementation side.Mentors or Reviewers
@petrochenkov
@tmandry
Process
The main points of the Major Change Process are as follows:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.