-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
non-pub function no longer compiled in debug profile, causing link errors on thumbv7em-none-eabihf with defmt #131164
Comments
it regressed both with and without --release. |
I also ran a bisect: searched nightlies: from nightly-2024-07-01 to nightly-2024-10-02 |
WG-prioritization assigning priority (Zulip discussion). I can also reproduce on current beta so tagging accordingly @rustbot label -I-prioritize +P-medium +regression-from-stable-to-beta |
minimized, zero deps -> https://github.com/Dirbaio/defmt-repro
|
maybe related: llvm/llvm-project@ebb326a |
It seems to all depend on the linker version, not the compiler itself. Using ldd from beta/nightly with a stable compiler triggers this issue. Using ldd from stable on a beta/nightly compiler doesn't. So I compiled lld from llvm myself, and can confirm: With lld built from commit Specifically, it seems to be this change: llvm/llvm-project@ebb326a#diff-efb0f6c06c654ed1044098de2bd75495d2fecd1730054dd26d41f0c9c93996e8R1582 If I revert that change (by simply changeing the if condition to |
This seems to be enough to "fix" this issue:
I put "fix" in quotes because is not meant as a solution: I didn't even try to understand what the if/else branches are meant to do. So it's quite likely that I broke something else with this change. (Verified on current LLVM |
the next stable release is in 9 days, at which point I believe the Ferrous Systems Embedded Rust exercises will stop compiling. |
Upstream issue: llvm/llvm-project#111478. |
Is anyone aware of a workaround we could apply for defmt? We would like to avoid defmt being broken on stable with the Rust release next week. I tried marking the Is there something we can add to the linker script? Something along the lines of Or can we pretend that this function is in fact used? Any pointer is much appreciated. |
Note that while the exercises are relatively small impact (as they are under our control), |
I have read the related code, maybe we need to add this symbol to the symbol table. Or change the code like this: diff --git a/lld/ELF/ScriptParser.cpp b/lld/ELF/ScriptParser.cpp
index 3febcfb87da4..44185c282ad7 100644
--- a/lld/ELF/ScriptParser.cpp
+++ b/lld/ELF/ScriptParser.cpp
@@ -1660,10 +1660,11 @@ Expr ScriptParser::readPrimary() {
tok = unquote(tok);
else if (!isValidSymbolName(tok))
setError("malformed number: " + tok);
- if (activeProvideSym)
+ if (activeProvideSym) {
ctx.script->provideMap[*activeProvideSym].push_back(tok);
- else
- ctx.script->referencedSymbols.push_back(tok);
+ return [] { return 0; };
+ }
+ ctx.script->referencedSymbols.push_back(tok);
return [=, s = ctx.script] { return s->getSymbolValue(tok, location); };
} However, I'm not familiar with this part of the code.
In any case, I believe the upstream backport is likely to miss our backport process. I'm reverting this commit to our fork LLVM. |
@DianQK said:
Would this mean this issue will not land on stable? That would be great, then we do not need to find a workaround for defmt. |
@rustbot label -P-medium +P-high |
Most concrete binary projects of It is very widely used in embedded software. |
The minimal reproduction is as follows:
#![no_main]
#![no_std]
#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
loop {}
}
#[no_mangle]
fn foo() {}
#[no_mangle]
fn bar() {}
$ rustc +beta main.rs --target thumbv7em-none-eabihf -Clink-arg=-Tscript.t
error: linking with `rust-lld` failed: exit status: 1
...
= note: rust-lld: error: script.t:1: symbol not found: bar
rust-lld: error: script.t:1: symbol not found: bar
rust-lld: error: script.t:1: symbol not found: bar
error: aborting due to 1 previous error With small modifications, it can also be reproduced on x86. @rustbot label +S-has-mcve +A-linkage |
Update LLVM submodule Fixes (maybe after beta backport) rust-lang#131164. r? nikic
Update LLVM submodule Fixes (maybe after beta backport) rust-lang#131164. r? nikic
Update LLVM submodule Fixes (maybe after beta backport) rust-lang#131164. r? nikic
Update LLVM submodule Fixes (maybe after beta backport) rust-lang#131164. r? nikic
I think this can be now closed, since #131448 has been backported and should have made it to the stable 1.82 release of tomorrrow. Am I right @jonathanpallant ? Can you check if we're all good here? thanks :) |
I can confirm nightly-2024-10-13 fixes it. nightly-2024-10-12 is the last one failing. Beta works as well. |
Upstream LLVM will not backport the relevant fixes, so I will add a test case. |
Do you think there is a chance that this "bug" will come back to us? We are currently evaluating if we should apply a fix/safeguard in defmt. |
No. The main branch of LLVM has fixed. The next major update will include it. |
Perfect! |
Lgtm |
Also tried with the stable prerelease from https://internals.rust-lang.org/t/rust-1-82-0-pre-release-testing/21705. Problem is solved. |
Add a test case for rust-lang#131164 The upstream has already been fixed, but it won't be backported to LLVM 19. r? jieyouxu or compiler
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#132002 (abi/compatibility: also test Option-like types) - rust-lang#132026 (analyse: remove unused uncanonicalized field) - rust-lang#132036 (Add a test case for rust-lang#131164) - rust-lang#132040 (relnotes: fix stabilizations of `assume_init`) r? `@ghost` `@rustbot` modify labels: rollup
Add a test case for rust-lang#131164 The upstream has already been fixed, but it won't be backported to LLVM 19. r? jieyouxu or compiler try-job: x86_64-gnu-stable
Add a test case for rust-lang#131164 The upstream has already been fixed, but it won't be backported to LLVM 19. r? jieyouxu or compiler try-job: x86_64-gnu-stable
Add a test case for rust-lang#131164 The upstream has already been fixed, but it won't be backported to LLVM 19. r? jieyouxu or compiler try-job: x86_64-gnu-stable
Rollup of 9 pull requests Successful merges: - rust-lang#130991 (Vectorized SliceContains) - rust-lang#131928 (rustdoc: Document `markdown` module.) - rust-lang#131955 (Set `signext` or `zeroext` for integer arguments on RISC-V and LoongArch64) - rust-lang#131979 (Minor tweaks to `compare_impl_item.rs`) - rust-lang#132036 (Add a test case for rust-lang#131164) - rust-lang#132039 (Specialize `read_exact` and `read_buf_exact` for `VecDeque`) - rust-lang#132060 ("innermost", "outermost", "leftmost", and "rightmost" don't need hyphens) - rust-lang#132065 (Clarify documentation of `ptr::dangling()` function) - rust-lang#132066 (Fix a typo in documentation of `pointer::sub_ptr()`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#132036 - DianQK:test-131164, r=jieyouxu Add a test case for rust-lang#131164 The upstream has already been fixed, but it won't be backported to LLVM 19. r? jieyouxu or compiler try-job: x86_64-gnu-stable
Code
I tried this code:
I expected to see this happen:
The binaries build like, they do on stable.
Instead, this happened:
That symbol is defined here: https://github.com/knurling-rs/defmt/blob/b7a89f56059fc66ac3c7cc3445d092829599e699/defmt/src/lib.rs#L365
Bisect
@Dirbaio said:
searched nightlies: from nightly-2024-07-30 to nightly-2024-10-02
regressed nightly: nightly-2024-08-01
searched commit range: f8060d2...28a58f2
regressed commit: 0b5eb7b
That's the LLVM 19 upgrade.
The text was updated successfully, but these errors were encountered: