-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Mangle rustc_std_internal_symbols functions #127173
base: master
Are you sure you want to change the base?
Conversation
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
Some changes occurred in compiler/rustc_codegen_gcc |
This comment has been minimized.
This comment has been minimized.
aea9a3c
to
db57b2a
Compare
This comment has been minimized.
This comment has been minimized.
db57b2a
to
4859689
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #127162) made this pull request unmergeable. Please resolve the merge conflicts. |
4859689
to
10bad43
Compare
This comment has been minimized.
This comment has been minimized.
The Miri subtree was changed cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
r? compiler |
Opened rust-lang/miri#3724 with some miri changes that can be made independently of this PR. |
Use the symbol_name query instead of trying to infer from the link_name attribute This prevents the calculated name from going out of sync with exported_symbols. It also avoids having to special case the panic_impl lang item. It also makes it easier to fix miri with rust-lang/rust#127173.
☔ The latest upstream changes (presumably #125507) made this pull request unmergeable. Please resolve the merge conflicts. |
Use the symbol_name query instead of trying to infer from the link_name attribute This prevents the calculated name from going out of sync with exported_symbols. It also avoids having to special case the panic_impl lang item. It also makes it easier to fix miri with rust-lang#127173.
e1d353a
to
f8f4b88
Compare
This comment has been minimized.
This comment has been minimized.
f8f4b88
to
266c7c2
Compare
This comment has been minimized.
This comment has been minimized.
266c7c2
to
9c91546
Compare
…bol, r=<try> Mangle rustc_std_internal_symbols functions This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`. Helps mitigate rust-lang#104707
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (e1a56e0): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -0.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 2.6%, secondary 2.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.1%, secondary 0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 760.23s -> 758.994s (-0.16%) |
The miri issue has been fixed. Ready for review. |
r? rust-lang/compiler |
That re-rolled the original reviewer. r? rust-lang/compiler |
e449918
to
4e87ee1
Compare
This comment has been minimized.
This comment has been minimized.
d0b59d6
to
39a1059
Compare
☔ The latest upstream changes (presumably #132512) made this pull request unmergeable. Please resolve the merge conflicts. |
39a1059
to
43723e1
Compare
☔ The latest upstream changes (presumably #132581) made this pull request unmergeable. Please resolve the merge conflicts. |
It currently implies #[no_mangle] which is alread an extern indicator, but this will change in a future commit.
This ensures that they will be correctly mangled in a future commit.
…ss #[no_mangle] is used
43723e1
to
87cb63d
Compare
This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and
__rust_no_alloc_shim_is_unstable
.Helps mitigate #104707