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

hexagon-unknown-none-elf cannot build core, "symbol 'fma' is already defined" #129823

Closed
saethlin opened this issue Aug 31, 2024 · 6 comments · Fixed by #129992
Closed

hexagon-unknown-none-elf cannot build core, "symbol 'fma' is already defined" #129823

saethlin opened this issue Aug 31, 2024 · 6 comments · Fixed by #129992
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@saethlin
Copy link
Member

In an empty #![no_std] Cargo project, run cargo +nightly build -Zbuild-std=core --target=hexagon-unknown-none-elf:

   Compiling compiler_builtins v0.1.123
   Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling byteorder v1.5.0
   Compiling zerocopy v0.7.34
error: symbol 'fma' is already defined

error: could not compile `compiler_builtins` (lib) due to 1 previous error

Pinging target maintainer @androm3da (Nobody is expecting you to fix this, just a heads-up)

@saethlin saethlin added C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 31, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Aug 31, 2024
@androm3da
Copy link
Contributor

Thanks for the heads up. I'll fix it.

@androm3da
Copy link
Contributor

Oh, err ... if I can reproduce it. I tried using rustc 1.82.0-nightly (0d634185d 2024-08-29) and didn't see the issue, but maybe I didn't make the test case quite right? In my case I didn't end up seeing byteorder, zerocopy dependencies being built.

But I looked around a bit, could this have shown up in 7240da0? If so, it seems plenty old enough to have been in scope for this nightly, so now I'm puzzled why I wouldn't encounter the issue.

$ cat src/lib.rs 
#![no_std]

pub fn add(left: usize, right: usize) -> usize {
    left + right
}
brian@yueh:~/src/testit$ cargo +nightly build -Zbuild-std=core --target=hexagon-unknown-none-elf
   Compiling compiler_builtins v0.1.123
   Compiling core v0.0.0 (/home/brian/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling rustc-std-workspace-core v1.99.0 (/home/brian/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling testit v0.1.0 (/home/brian/src/testit)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.31s

androm3da added a commit to CodeLinaro/compiler-builtins that referenced this issue Aug 31, 2024
These hexagon builtins incorrectly created aliases in the global
namespace which can (and in at least one case, did) conflict
with symbols defined by other programs.

This should address the issue reported as rust-lang/rust#129823:

	   Compiling compiler_builtins v0.1.123
	   Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
	   Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
	   Compiling byteorder v1.5.0
	   Compiling zerocopy v0.7.34
	error: symbol 'fma' is already defined

	error: could not compile `compiler_builtins` (lib) due to 1 previous error

Also: some of the symbols defined were not just aliases, so those are
now qualified with `__hexagon_`.  The compiler does not yet emit calls
to these particular ones, but if/when it does, it can use the new names.
@saethlin
Copy link
Member Author

The zerocopy and byteorder were me looking at something else. Sorry about that.

But even if I remove them, I still get this error:

╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ cargo +nightly build -Zbuild-std=core --target=hexagon-unknown-none-elf
   Compiling compiler_builtins v0.1.123
   Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling scratch v0.1.0 (/tmp/scratch)
error: symbol 'fma' is already defined

error: could not compile `compiler_builtins` (lib) due to 1 previous error
╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ rustc +nightly -vV
rustc 1.82.0-nightly (0d634185d 2024-08-29)
binary: rustc
commit-hash: 0d634185dfddefe09047881175f35c65d68dcff1
commit-date: 2024-08-29
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0
╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ cat src/lib.rs 
#![no_std]
pub fn add(left: usize, right: usize) -> usize {
    left + right
}

@androm3da
Copy link
Contributor

I'm not quite sure why I can't reproduce the problem. But maybe that's moot because it's clear that my contribution to compiler-builtins is wrong.

But even if I remove them, I still get this error:

You're right - I think this should fix it - rust-lang/compiler-builtins#682

@saethlin
Copy link
Member Author

saethlin commented Aug 31, 2024

Like all things related to linkage, it looks like a codegen-units issue. Behold:

╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ cargo +nightly build -Zbuild-std=core --target=hexagon-unknown-none-elf
   Compiling compiler_builtins v0.1.123
   Compiling scratch v0.1.0 (/tmp/scratch)
error: symbol 'fma' is already defined

error: could not compile `compiler_builtins` (lib) due to 1 previous error
╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ RUSTFLAGS=-Ccodegen-units=1 cargo +nightly build -Zbuild-std=core --target=hexagon-unknown-none-elf
   Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.123
   Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling scratch v0.1.0 (/tmp/scratch)
error: symbol 'fma' is already defined

error: symbol 'fmin' is already defined

error: symbol 'fmax' is already defined

error: could not compile `compiler_builtins` (lib) due to 3 previous errors
warning: build failed, waiting for other jobs to finish...
╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ RUSTFLAGS=-Ccodegen-units=4096 cargo +nightly build -Zbuild-std=core --target=hexagon-unknown-none-elf
   Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.123
   Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling scratch v0.1.0 (/tmp/scratch)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.80s

The standard library has a profile override for compiler_builtins which clearly isn't being applied here (the code says profile.release but you can get the same diagnostics as above if you add --release):

rust/library/Cargo.toml

Lines 14 to 25 in a7399ba

[profile.release.package.compiler_builtins]
# For compiler-builtins we always use a high number of codegen units.
# The goal here is to place every single intrinsic into its own object
# file to avoid symbol clashes with the system libgcc if possible. Note
# that this number doesn't actually produce this many object files, we
# just don't create more than this number of object files.
#
# It's a bit of a bummer that we have to pass this here, unfortunately.
# Ideally this would be specified through an env var to Cargo so Cargo
# knows how many CGUs are for this specific crate, but for now
# per-crate configuration isn't specifiable in the environment.
codegen-units = 10000

Is this error we're looking at the sort of thing this override is supposed to prevent? It mentions "the system libgcc" and I definitely do not have a hexagon libgcc, if such a thing even exists. I'm trying to figure out if I should be filing a bug about -Zbuild-std ignoring library/Cargo.toml. Probably?

@saethlin saethlin added A-linkage Area: linking into static, shared libraries and binaries and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Aug 31, 2024
@androm3da
Copy link
Contributor

The compiler-builtins PR should fix it. I am not yet familiar with the override but I don't think it's related/necessary.

workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 11, 2024
…ins, r=tgross35

Update compiler-builtins to 0.1.125

This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are:

* rust-lang/compiler-builtins#682
* rust-lang/compiler-builtins#678
* rust-lang/compiler-builtins#685

Fixes: rust-lang#129823
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 C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
3 participants