[llvm] Allow Rust personality name to contain arbitrary prefix

[Noratrieb]

LLVM needs to figure out the type of EH personality for various reasons. To do this, it currently matches against a hardcoded list of names. In Rust, we would like to mangle our personality function to better support linking multiple Rust standard libraries via staticlib. We have currently mangled all symbols except the personality, which remains unmangled because of this LLVM hardcoding.

Instead, this now does a suffix match of the personality name, which will work with the mangling scheme used for these internal symbols (e.g. _RNvCseCSg29WUqSe_7___rustc12___rust_alloc).

Companion Rust PR: rust-lang/rust#148413

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-llvm-ir

Author: nora (Noratrieb)

Changes

LLVM needs to figure out the type of EH personality for various reasons. To do this, it currently matches against a hardcoded list of names. In Rust, we would like to mangle our personality function to better support linking multiple Rust standard libraries via staticlib. We have currently mangled all symbols except the personality, which remains unmangled because of this LLVM hardcoding.

Instead, this now does a suffix match of the personality name, which will work with the mangling scheme used for these internal symbols (e.g. _RNvCseCSg29WUqSe_7___rustc12___rust_alloc).

---

Full diff: https://github.com/llvm/llvm-project/pull/166095.diff

1 Files Affected:

• (modified) llvm/lib/IR/EHPersonalities.cpp (+4-2)

diff --git a/llvm/lib/IR/EHPersonalities.cpp b/llvm/lib/IR/EHPersonalities.cpp
index 9297a82e7d2b0..12ae4748e1f4a 100644
--- a/llvm/lib/IR/EHPersonalities.cpp
+++ b/llvm/lib/IR/EHPersonalities.cpp
@@ -47,7 +47,8 @@ EHPersonality llvm::classifyEHPersonality(const Value *Pers) {
       .Case("__C_specific_handler", EHPersonality::MSVC_TableSEH)
       .Case("__CxxFrameHandler3", EHPersonality::MSVC_CXX)
       .Case("ProcessCLRException", EHPersonality::CoreCLR)
-      .Case("rust_eh_personality", EHPersonality::Rust)
+      // Rust mangles its personality function, so we can't test exact equality.
+      .EndsWith("rust_eh_personality", EHPersonality::Rust)
       .Case("__gxx_wasm_personality_v0", EHPersonality::Wasm_CXX)
       .Case("__xlcxx_personality_v1", EHPersonality::XL_CXX)
       .Case("__zos_cxx_personality_v2", EHPersonality::ZOS_CXX)
@@ -77,7 +78,8 @@ StringRef llvm::getEHPersonalityName(EHPersonality Pers) {
   case EHPersonality::CoreCLR:
     return "ProcessCLRException";
   case EHPersonality::Rust:
-    return "rust_eh_personality";
+    llvm_unreachable(
+        "Cannot get personality name of Rust personality, since it is mangled");
   case EHPersonality::Wasm_CXX:
     return "__gxx_wasm_personality_v0";
   case EHPersonality::XL_CXX:

[Noratrieb]

@rnk @nikic

[github-actions]

⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo.
Please turn off Keep my email addresses private setting in your account.
See LLVM Developer Policy and LLVM Discourse for more information.

[rnk]

I would ask for a test, but a unit test here feels trivial, and there is very little observable behavior hooked up to the EH personality classification routine that distinguishes between unknown EH personalities and the Rust personality. The only hit I found was in InstCombine:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L4672

[rnk]

This worried me enough to audit the callers of this function:

../llvm/include/llvm/IR/EHPersonalities.h:LLVM_ABI StringRef getEHPersonalityName(EHPersonality Pers);
../llvm/lib/IR/EHPersonalities.cpp:StringRef llvm::getEHPersonalityName(EHPersonality Pers) {
../llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp:    StringRef PersName = getEHPersonalityName(EHPersonality::Wasm_CXX);
../llvm/lib/Transforms/Utils/EscapeEnumerator.cpp:  return M->getOrInsertFunction(getEHPersonalityName(Pers),

The most interesting case was the EscapeEnumerator, which needs to compute the name of the default EH personality so it can insert new cleanup landingpads. Presumably the Rust EH personality will never be the platform default EH personality, so there's no correctness issue.

If we wanted to be super-safe we'd make the return value optional or return an empty string, but this seems OK to me as written.

[Noratrieb]

Yeah I also thought about making a est but wasn't really sure what could be meaningfully tested here, other than just having a personality symbol with a mangled name, which probably isn't that useful in the end.

[Noratrieb]

test\Analysis\CostModel\AArch64\sincos.ll:41:17: error: SINCOS_STRET: expected string not found in input failed on both Linux and Windows, which seems like an unrelated failure? https://github.com/llvm/llvm-project/actions/runs/19079423980/job/54529717418

I rebased against latest main and ran check-llvm locally on my Linux system and all tests passed (I didn't do that originally because I had some trouble getting LLVM to build, but now it worked)

[rnk]

Yeah, that's surely unrelated. If it goes in with a re-run, great, otherwise, we'll revisit.

[Noratrieb]

Looks like it passed now! I don't have commit access, so could you merge it for me please?

[github-actions]

@Noratrieb Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!