-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RWPI/ROPI relocation model support #41560
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Adds support for using LLVM 4's ROPI and RWPI relocation models for ARM
Hmm, this is a bit out of my wheelhouse. Perhaps @nagisa, @eddyb, or @michaelwoerister would be a better fit? |
I didn't realize how short this PR is. @alevy, I think the main question is: is there any way to write a test for this? |
@alevy You should repeat what we did for other |
@eddyb thanks for the suggestion, I implemented something like @nikomatsakis Tests would be nice, I'm just not sure where to put them. A quick grep for |
src/rustllvm/PassWrapper.cpp
Outdated
LLVMRustRelocModeDynamicNoPic, | ||
LLVMRustRelocModeROPI, | ||
LLVMRustRelocModeRWPI, | ||
LLVMRustRelocModeROPIRWPI, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need the prefix on each one, that's why it's enum class
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh duh.... fixed.
@alevy I think the |
src/librustc_llvm/ffi.rs
Outdated
@@ -288,6 +288,9 @@ pub enum RelocMode { | |||
Static = 1, | |||
PIC = 2, | |||
DynamicNoPic = 3, | |||
ROPI = 4, | |||
RWPI = 5, | |||
ROPI_RWPI = 6, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you won't have numbers in the C++ bindings, you should remove them here, btw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, do you think it makes more sense to add numbers in the C++ or remove them here? (the other C++ enums don't have them, so I'm assuming remove them here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, removing is fine. As long as they look the same, they'll behave the same.
Replaces the llvm-c exposed LLVMRelocMode, which does not include all relocation model variants, with a LLVMRustRelocMode modeled after LLVMRustCodeMode.
OK @eddyb I think I've addressed your comments. Thanks! |
@bors r+ |
@bors doesn't seem to like this PR for some reason? |
@bors r+ |
@bors: r=eddyb |
📌 Commit 0f00f27 has been approved by |
Add RWPI/ROPI relocation model support This PR adds support for using LLVM 4's ROPI and RWPI relocation models for ARM. ROPI (Read-Only Position Independence) and RWPI (Read-Write Position Independence) are two new relocation models in LLVM for the ARM backend ([LLVM changset](https://reviews.llvm.org/rL278015)). The motivation is that these are the specific strategies we use in userspace [Tock](https://www.tockos.org) apps, so supporting this is an important step (perhaps the final step, but can't confirm yet) in enabling userspace Rust processes. ## Explanation ROPI makes all code and immutable accesses PC relative, but not assumed to be overriden at runtime (so for example, jumps are always relative). RWPI uses a base register (`r9`) that stores the addresses of the GOT in memory so the runtime (e.g. a kernel) only adjusts r9 tell running code where the GOT is. ## Complications adding support in Rust While this landed in LLVM master back in August, the header files in `llvm-c` have not been updated yet to reflect it. Rust replicates that header file's version of the `LLVMRelocMode` enum as the Rust enum `llvm::RelocMode` and uses an implicit cast in the ffi to translate from Rust's notion of the relocation model to the LLVM library's notion. My workaround for this currently is to replace the `LLVMRelocMode` argument to `LLVMTargetMachineRef` with an int and using the hardcoded int representation of the `RelocMode` enum. This is A Bad Idea(tm), but I think very nearly the right thing. Would a better alternative be to patch rust-llvm to support these enum variants (also a fairly trivial change)?
☀️ Test successful - status-appveyor, status-travis |
This PR adds support for using LLVM 4's ROPI and RWPI relocation models for ARM.
ROPI (Read-Only Position Independence) and RWPI (Read-Write Position Independence) are two new relocation models in LLVM for the ARM backend (LLVM changset). The motivation is that these are the specific strategies we use in userspace Tock apps, so supporting this is an important step (perhaps the final step, but can't confirm yet) in enabling userspace Rust processes.
Explanation
ROPI makes all code and immutable accesses PC relative, but not assumed to be overriden at runtime (so for example, jumps are always relative).
RWPI uses a base register (
r9
) that stores the addresses of the GOT in memory so the runtime (e.g. a kernel) only adjusts r9 tell running code where the GOT is.Complications adding support in Rust
While this landed in LLVM master back in August, the header files in
llvm-c
have not been updated yet to reflect it. Rust replicates that header file's version of theLLVMRelocMode
enum as the Rust enumllvm::RelocMode
and uses an implicit cast in the ffi to translate from Rust's notion of the relocation model to the LLVM library's notion.My workaround for this currently is to replace the
LLVMRelocMode
argument toLLVMTargetMachineRef
with an int and using the hardcoded int representation of theRelocMode
enum. This is A Bad Idea(tm), but I think very nearly the right thing.Would a better alternative be to patch rust-llvm to support these enum variants (also a fairly trivial change)?