-
Notifications
You must be signed in to change notification settings - Fork 13.4k
rust_eh_personality exported in cdylibs #100774
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I believe this has been fixed since Rust 1.62.0. $ printf '%s' '#[no_mangle] pub extern "C" fn my() { std::panic::catch_unwind(|| println!("hello")).unwrap(); }' \
| rustc --crate-type=cdylib - && dyld_info -exports librust_out.dylib
librust_out.dylib [arm64]:
-exports:
offset symbol
0x000048E0 _my On
@rustbot label: +I-compiler-nominated +A-linkage |
@XrXr can you add a bit of context for the T-compiler nomination label? Are you looking for a discussion whether the general problem is actually resolved (assuming your intent is to close this issue)? @dkg do you have an opinion or additional context? Rust 1.62.0 was released in June 2022, before this issue was opened thanks! |
Yes, I'm looking to close the issue. I believe in general the personality symbol is now never exported from cdylibs (without the user code doing it explicitly, anyways). T-compiler can verify this claim. Note, I think #95604 that fixed it. |
Discussed briefly at T-compiler meeting. I'm willing to believe #95604 fixed this, and @wesleywiser says the behavior appears to be working well on Windows-MSVC as well. Assigning self to investigate, and maybe add some run-make tests for the described scenario(s). @rustbot label: -I-compiler-nominated |
fwiw, when i opened this issue, i was running a rustc earlier than 1.62. I can confirm the results that @XrXr posted above for newer versions of rustc. |
Can this be closed? |
If i have two shared objects, each created by rust using a
cdylib
crate, and they are both invoked from an external (non-rust) executable, it's unusual that both of these libraries will implement and export arust_eh_personality
symbol.If, for whatever reason, the external executable tries to invoke
rust_eh_personality
, which library's function call will be invoked?If the two dylibs are built by different versions of rust, or with different options, presumably the
rust_eh_personality
function will differ.(even worse would be if any internal code in either shared object invoked
rust_eh_personality
by the process's symbol table, but i'm assuming that internal code references its ownrust_eh_personality
internally)Unless there is a clear reason to export the
rust_eh_personality
symbol, it ought to be non-exported by default so that multiplecdylib
objects can be loaded without colliding symbols.I note #92102 raises the same concern, but it seems to be resolved without having stopped exporting
rust_eh_personality
.https://users.rust-lang.org/t/hiding-rust-eh-personality-symbol-in-cdylib/60490 also discusses the matter, but i don't see how it is resolved in the general case.
The text was updated successfully, but these errors were encountered: