Skip to content

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

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

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

No branches or pull requests

6 participants