Skip to content
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

rust_eh_personality exported in cdylibs #100774

Closed
dkg opened this issue Aug 19, 2022 · 7 comments
Closed

rust_eh_personality exported in cdylibs #100774

dkg opened this issue Aug 19, 2022 · 7 comments
Assignees
Labels
A-linkage Area: linking into static, shared libraries and binaries

Comments

@dkg
Copy link

dkg commented Aug 19, 2022

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 a rust_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 own rust_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 multiple cdylib 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.

@XrXr
Copy link
Contributor

XrXr commented Mar 21, 2023

I believe this has been fixed since Rust 1.62.0.
On 1.68.0-aarch64-apple-darwin (Mach-O):

$ 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 1.68.0--x86_64-unknown-linux-gnu (ELF):

$ printf '%s' '#[no_mangle] pub extern "C" fn my() { std::panic::catch_unwind(|| println!("hello")).unwrap(); }' \ 
    | rustc --crate-type=cdylib - && nm --defined-only --extern-only librust_out.so
0000000000007270 T my

@rustbot label: +I-compiler-nominated +A-linkage

@rustbot rustbot added A-linkage Area: linking into static, shared libraries and binaries I-compiler-nominated Nominated for discussion during a compiler team meeting. labels Mar 21, 2023
@apiraino
Copy link
Contributor

@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!

@XrXr
Copy link
Contributor

XrXr commented Mar 22, 2023

Are you looking for a discussion whether the general problem is actually resolved (assuming your intent is to close this issue)?

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.

@pnkfelix pnkfelix self-assigned this Mar 23, 2023
@pnkfelix
Copy link
Member

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

@rustbot rustbot removed the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Mar 23, 2023
@dkg
Copy link
Author

dkg commented Apr 2, 2023

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.

@bjorn3
Copy link
Member

bjorn3 commented Jul 13, 2023

Can this be closed?

@apiraino
Copy link
Contributor

@dkg @XrXr I am going to close this issue as solved, please feel free to reopen if it's the case.

thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries
Projects
None yet
Development

No branches or pull requests

6 participants