Skip to content

Conversation

PiJoules
Copy link

@PiJoules PiJoules commented Aug 5, 2025

This is a WIP patch for implementing rust-lang/compiler-team#903. It adds a new unstable flag -Zexperimental-relative-rust-abi-vtables that makes vtables PIC-friendly. This is only supported for LLVM codegen and not supported for other backends.

Early feedback on this is welcome. I'm not sure if how I implemented it is the best way of doing so since much of the actual vtable emission is heavily done during LLVM codegen. That is, the vtable to MIR looks like a normal table of pointers and byte arrays and I really only make the vtables relative on the codegen level.

Locally, I can build the stage 1 compiler and runtimes with relative vtables, but I couldn't figure out how to tell the build system to only build stage 1 binaries with this flag, so I work around this by unconditionally enabling relative vtables in rustc. The end goal I think we'd like is either something akin to multilibs in clang where the compiler chooses which runtimes to use based off compilation flags, or binding this ABI to the target and have it be part of the default ABI for that target (just like how relative vtables are the default for Fuchsia in C++ with Clang). I think the later is what target modifiers do (#136966).

Action Items:

  • I'm still experimenting with building Fuchsia with this to assert it works e2e and I still need to do some measurements to see if this is still worth pursuing.
  • More work will still be needed to ensure the correct relative intrinsics are emitted with CFI and LTO. Rn I'm experimenting on a normal build.

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 5, 2025
@rust-log-analyzer

This comment has been minimized.

@PiJoules PiJoules force-pushed the WIP-relative-vtables branch from 5217fd7 to 0ace3e7 Compare August 5, 2025 22:31
@rust-log-analyzer

This comment has been minimized.

@bjorn3
Copy link
Member

bjorn3 commented Aug 6, 2025

I wonder how hard it would be to store true 32bit pointers in the const eval allocation for the vtable. That would avoid all hacks elsewhere around the size mismatch between const eval and runtime.

This is a WIP patch for implementing
rust-lang/compiler-team#903. It adds a new
unstable flag `-Zexperimental-relative-rust-abi-vtables` that makes
vtables PIC-friendly. This is only supported for LLVM codegen and
not supported for other backends.

Early feedback on this is welcome. I'm not sure if how I implemented it
is the best way of doing so since much of the actual vtable emission is
heavily done during LLVM codegen. That is, the vtable to MIR looks like
a normal table of pointers and byte arrays and I really only make the
vtables relative on the codegen level.

Locally, I can build the stage 1 compiler and runtimes with relative
vtables, but I couldn't figure out how to tell the build system to only
build stage 1 binaries with this flag, so I work around this by
unconditionally enabling relative vtables in rustc. The end goal I think
we'd like is either something akin to multilibs in clang where the
compiler chooses which runtimes to use based off compilation flags, or
binding this ABI to the target and have it be part of the default ABI
for that target (just like how relative vtables are the default for
Fuchsia in C++ with Clang). I think the later is what target modifiers
do (rust-lang#136966).

Action Items:

- I'm still experimenting with building Fuchsia with this to assert it
  works e2e and I still need to do some measurements to see if this is
  still worth pursuing.
- More work will still be needed to ensure the correct relative
  intrinsics are emitted with CFI and LTO. Rn I'm experimenting on a normal
  build.
@PiJoules PiJoules force-pushed the WIP-relative-vtables branch from 0ace3e7 to d58809f Compare August 7, 2025 21:48
@rust-log-analyzer
Copy link
Collaborator

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
All checks passed!
checking python file formatting
27 files already formatted
checking C++ file formatting
/checkout/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp:620:64: error: code should be clang-formatted [-Wclang-format-violations]
extern "C" LLVMValueRef LLVMBuildLoadRelative(LLVMBuilderRef B, LLVMValueRef Ptr,
                                                               ^
/checkout/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp:623:44: error: code should be clang-formatted [-Wclang-format-violations]
  Value *call = unwrap(B)->CreateIntrinsic(
                                           ^
/checkout/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp:624:43: error: code should be clang-formatted [-Wclang-format-violations]
      Intrinsic::load_relative, {Int32Ty}, {unwrap(Ptr), unwrap(ByteOffset)});
                                          ^

clang-format linting failed! Printing diff suggestions:
--- /checkout/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp (actual)
+++ /checkout/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp (formatted)
@@ -616,13 +616,14 @@
   LI->setAtomic(fromRust(Order));
   return wrap(LI);
 }
 
-extern "C" LLVMValueRef LLVMBuildLoadRelative(LLVMBuilderRef B, LLVMValueRef Ptr,
+extern "C" LLVMValueRef LLVMBuildLoadRelative(LLVMBuilderRef B,
+                                              LLVMValueRef Ptr,
                                               LLVMValueRef ByteOffset) {
   Type *Int32Ty = Type::getInt32Ty(unwrap(B)->getContext());
-  Value *call = unwrap(B)->CreateIntrinsic(
-      Intrinsic::load_relative, {Int32Ty}, {unwrap(Ptr), unwrap(ByteOffset)});
+  Value *call = unwrap(B)->CreateIntrinsic(Intrinsic::load_relative, {Int32Ty},
+                                           {unwrap(Ptr), unwrap(ByteOffset)});
   return wrap(call);
 }
 
 extern "C" LLVMValueRef LLVMRustBuildAtomicStore(LLVMBuilderRef B,

tidy error: checks with external tool 'clang-format' failed
some tidy checks failed
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:01:16
  local time: Thu Aug  7 21:52:56 UTC 2025
  network time: Thu, 07 Aug 2025 21:52:56 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

@bors
Copy link
Collaborator

bors commented Oct 8, 2025

☔ The latest upstream changes (presumably #147475) made this pull request unmergeable. Please resolve the merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants