compiler_builtins string.h functions are not available when using std targets with #![no_std] #137833

Activity

1. byeongkeunahn

   added

   C-bugCategory: This is a bug.Category: This is a bug.

   regression-untriagedUntriaged performance or correctness regression.Untriaged performance or correctness regression.

   on Mar 1, 2025
2. rustbot

   added

   I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}Issue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}

   needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triagingThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging

   on Mar 1, 2025
3. tgross35 commented on Mar 1, 2025

   

   tgross35

   on Mar 1, 2025

   Last edited by tgross35

   Member

   More actions

   Thanks for bisecting already. I don't think the compiler changes in #135501 should have affected Cargo features at all since that only affects when the already-built compiler-builtins crate gets injected; however, I am wondering whether the changes from public to private in Cargo.toml may have changed the way features get are getting enabled. Cc @rust-lang/cargo in case anybody knows of some behavior differences here.

   Are you able to build rustc? That theory can probably be tested by reverting 8c1b49d (Use public-dependencies in all sysroot crates) which shouldn't affect anything else.

   Separately, it may be useful if you can post the output of nm -gC libcompiler_builtins-hash.rlib for that target (just search for libcompiler_builtins in the rustc sysroot to get the right file) to see what exactly the story is for available symbols. nevermind, that part is reasonably straightforward.
4. saethlin commented on Mar 1, 2025

   

   saethlin

   on Mar 1, 2025

   Member

   More actions

   Are you able to build rustc?

   Why is this relevant? Maybe you know something about basm that I don't know, but AFAIK the problem is this:
   https://github.com/boj-rs/basm-rs/blob/2e3799d684b6fc3f9db672b8f077966c5ee04541/basm/Cargo.toml#L32-L45

   I was previously advised by t-libs that adding a Cargo dependency on the published compiler-builtins is not a use of the library that is supported, and indeed I ran into many strange linkage and crate resolution issues when I was trying to do that.
5. byeongkeunahn commented on Mar 1, 2025

   

   byeongkeunahn

   on Mar 1, 2025

   Author

   More actions

   Are you able to build rustc?

   I'm not familiar with building rustc, I'll give it a try when I have time. Thanks for the suggestion :)

   I was previously advised by t-libs that adding a Cargo dependency on the published compiler-builtins is not a use of the library that is supported, and indeed I ran into many strange linkage and crate resolution issues when I was trying to do that.

   I appreciate that this is not an intended use case. However, in that case, the issue is that the linking error persists when the compiler-builtins dependency is removed from Cargo.toml. If I recall correctly, the compiler-builtins dependency was added a few years ago to resolve the same linker error regarding undefined external symbols (memcpy/memset/strlen).
6. tgross35 commented on Mar 1, 2025

   

   tgross35

   on Mar 1, 2025

   Member

   More actions

   I know nothing about basm but the original post says:

   Adding/removing compiler-builtins with mem feature enabled (on Cargo.toml) doesn't alleviate the issue.

   I assumed this meant they were still seeing a regression across the versions even if they removed the compiler_builtins dependency. Why that project has the dependency in the first place, I have no idea.

   (But yeah, we need to do something about compiler-builtins on crates.io once we understand whether there are any remaining legitimate usecases, syncs have me very pretty of that not being a submodule/tree anyway. On my eventual todo list...)
7. tgross35 commented on Mar 1, 2025

   

   tgross35

   on Mar 1, 2025

   Member

   More actions

   I'm not familiar with building rustc, I'll give it a try when I have time. Thanks for the suggestion :)

   It's reasonably easy, ./x build --stage 1, then run the commands from https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#creating-a-rustup-toolchain so you can cargo +stage1 build .... The rest of page has more details.

   If you can reproduce this with a smaller crate, I'll also try to take a closer look over the weekend.
8. byeongkeunahn commented on Mar 1, 2025

   

   byeongkeunahn

   on Mar 1, 2025

   Last edited by byeongkeunahn

   Author

   More actions

   If you can reproduce this with a smaller crate, I'll also try to take a closer look over the weekend.

   I've constructed a minimized version which runs on x64 Windows only. It is set to use nightly-2025-02-23. Any of the following changes will make cargo run fail with linker errors:

   • When the compiler-builtins dependency is commented out
   • When the nightly version is changed to nightly-2025-02-24
   • When rustflags = ["-C", "target-cpu=haswell"] in .cargo/config.toml is removed

   Furthermore, while the minimized version does not have issues with cargo run --release, the original (full) repo still fails with linker errors.

   Please find the minimal example below.

   basm-rs-minimal-example.zip

   It is possible that I might be using the no-std feature incorrectly. Please let me know if that is the case.
9. bjorn3 commented on Mar 1, 2025

   

   bjorn3

   on Mar 1, 2025

   Member

   More actions

   Does it work if you keep the compiler-builtins dependency with the mem feature enabled but add extern crate compiler_builtins; to your source code?
10. byeongkeunahn commented on Mar 1, 2025

    

    byeongkeunahn

    on Mar 1, 2025

    Last edited by byeongkeunahn

    Author

    More actions

    Oh yes, that seems to work on nightly-2025-02-24 and afterwards. More precisely, the following works:

    extern crate compiler_builtins;
    extern crate alloc;
    

    However, when the order is reversed, linking error persists:

    extern crate alloc;
    extern crate compiler_builtins;
    

    I've observed the same tendency in both the minimal example and the original repo.

    Unfortunately, cargo fmt (which we check for on CI) prefers the latter ordering.
11. Noratrieb

    added

    A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binaries

    and removed

    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triagingThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging

    on Mar 1, 2025
12. tgross35 commented on Mar 1, 2025

    

    tgross35

    on Mar 1, 2025

    Member

    More actions

    Oh yes, that seems to work on nightly-2025-02-24 and afterwards. More precisely, the following works:

    extern crate compiler_builtins;
    extern crate alloc;
    

    However, when the order is reversed, linking error persists:

    extern crate alloc;
    extern crate compiler_builtins;
    

    I'm guessing the difference is that with the first version and before #135501, the crates.io version built with mem gets picked up and I think you wind up with both in the graph. But with the second version it's getting compiler_builtins from alloc's graph first (which is the sysroot version without mem) and so it doesn't add compiler_builtins again due to the check at

    rust/compiler/rustc_metadata/src/creader.rs

    Lines 1124 to 1131 in 8c39296

    	// If a `#![compiler_builtins]` crate already exists, avoid injecting it twice. This is
    	// the common case since usually it appears as a dependency of `std` or `alloc`.
    	for (cnum, cmeta) in self.cstore.iter_crate_data() {
    	if cmeta.is_compiler_builtins() {
    	info!("`compiler_builtins` already exists (cnum = {cnum}); skipping injection");
    	return;
    	}
    	}

    . This could probably be verified by running with RUSTC_LOG=rustc_metadata::creader=info and comparing the output between the two.

    Removing target-cpu=haswell and running with or without --release probably just changes codegen such that the missing symbols are sometimes needed at all. This could also be looking at your crate's .rlib before link with the different flag combinations and seeing whether or not there is an undefined symbol memcpy (I think the Windows equivalent of nm to check this is dumpbin?).

    Why are you passing /NODEFAULTLIB in build.rs? I'm assuming this is why it isn't just using the system's library. We don't distribute compiler_builtins with the mem feature on Windows to avoid conflicting with the system libs.
13. byeongkeunahn commented on Mar 2, 2025

    

    byeongkeunahn

    on Mar 2, 2025

    Author

    More actions

    Why are you passing /NODEFAULTLIB in build.rs? I'm assuming this is why it isn't just using the system's library. We don't distribute compiler_builtins with the mem feature on Windows to avoid conflicting with the system libs.

    It was to reduce the binary size whenever possible. Nevertheless, the linker error pattern doesn't change even if /NODEFAULTLIB is removed.

    basm-rs-minimal-example-v2.zip
14. tgross35 commented on Mar 2, 2025

    

    tgross35

    on Mar 2, 2025

    Last edited by tgross35

    Member

    More actions

    Reduced:

    #![no_main]
    #![no_std]
    
    extern crate alloc;
    
    struct Allocator;
    
    unsafe impl core::alloc::GlobalAlloc for Allocator {
        unsafe fn alloc(&self, _: core::alloc::Layout) -> *mut u8 {
            unimplemented!()
        }
        unsafe fn alloc_zeroed(&self, _: core::alloc::Layout) -> *mut u8 {
            unimplemented!()
        }
        unsafe fn dealloc(&self, _: *mut u8, _: core::alloc::Layout) {}
        unsafe fn realloc(&self, _: *mut u8, _: core::alloc::Layout, _: usize) -> *mut u8 {
            unimplemented!()
        }
    }
    
    #[global_allocator]
    static ALLOC: Allocator = Allocator;
    
    #[unsafe(no_mangle)]
    extern "win64" fn __CxxFrameHandler3() -> ! {
        unimplemented!()
    }
    
    #[panic_handler]
    fn panic(_pi: &core::panic::PanicInfo) -> ! {
        unimplemented!()
    }
    
    #[unsafe(no_mangle)]
    pub unsafe extern "win64" fn _basm_start() -> ! {
        unimplemented!()
    }

    With rustc src\lib.rs -Cpanic=abort -C link-arg=/SUBSYSTEM:CONSOLE -C link-arg=/ENTRY:_basm_start, the same symbols are missing (memcpy, memset, memmove etc).

    Run with RUSTC_LOG=rustc_metadata::creader=info makes it pretty clear that after #135501, a non-sysroot compiler_builtins doesn't get into the crate graph unless added early with extern crate compiler_builtins, but for older versions it allowed duplicates. It is possible to adjust that part of resolution to allow >1 compiler_builtins crate (by deleting the block I linked above).

    I am hesitant to do that though because the current behavior is generally preferable; we want to discourage direct use of compiler_builtins, and enabling multiple versions to be linked is an absolute disaster waiting to happen (E.g. we recently changed the function signatures on our i128 overflowing multiplication symbols).

    I'm not sure what a better solution is, however. Maybe it's easiest to enable mem in the distributed version on Windows and make the symbols weak? We do this for other symbols, with a caveat that I think this doesn't work for windows-gnu.

    Cc @ChrisDenton, do you have any ideas?
15. byeongkeunahn commented on Mar 2, 2025

    

    byeongkeunahn

    on Mar 2, 2025

    Author

    More actions

    Thank you for the detailed analysis. One thing I'd like to note is that the linker error also occurs on Linux, not just Windows. The error message on Linux can be found at the beginning of this issue thread. The reason I limited the above example to Windows was simply to minimize the amount of code.
16. tgross35 commented on Mar 2, 2025

    

    tgross35

    on Mar 2, 2025

    Member

    More actions

    Ah, I thought we were providing the symbols on Unix because weak linkage works well, but I guess bootstrap only sets this for no_std targets

    rust/src/bootstrap/src/core/build_steps/compile.rs

    Line 601 in 1c3b035

    features += " compiler-builtins-mem";

    .
17. tgross35

    changed the title [-]no-std build fails on Windows/Linux x64[/-] [+]`compiler_builtins` `string.h` functions are not available when using `std` targets with `#![no_std]`[/+] on Mar 2, 2025
18. apiraino

    added

    E-needs-investigationCall for participation: This issues needs some investigation to determine current statusCall for participation: This issues needs some investigation to determine current status

    on Mar 6, 2025
19. landaire commented on Mar 28, 2025

    

    landaire

    on Mar 28, 2025

    Last edited by landaire

    Contributor

    More actions

    I'm unsure if this is related, but I also hit this issue and after using the extern crate workaround mentioned above hit a different issue:

    Linker Error

    error: linking with `link.exe` failed: exit code: 1120
      |
      = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "/NODEFAULTLIB" "C:\\Users\\lander\\AppData\\Local\\Temp\\rustcsrdZhG\\symbols.o" "<1 object files omitted>" "C:\\Users\\lander\\dev\\solstice\\crates\\shellcode_stage1_network\\target\\x86_64-pc-windows-msvc\\release\\deps/{libcompiler_builtins-b938875b878c1ff4.rlib}.rlib" "C:\\Users\\lander\\.cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\windows_x86_64_msvc-0.52.6\\lib\\windows.0.52.0.lib" "/defaultlib:msvcrt" "/NXCOMPAT" "/LIBPATH:C:\\Users\\lander\\.cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\windows_x86_64_msvc-0.52.6\\lib" "/OUT:C:\\Users\\lander\\dev\\solstice\\crates\\shellcode_stage1_network\\target\\x86_64-pc-windows-msvc\\release\\deps\\shellcode_stage1_network.exe" "/OPT:REF,ICF" "/DEBUG" "/PDBALTPATH:%_PDB%" "/NATVIS:\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:\\lib\\rustlib\\etc\\libcore.natvis" "/NATVIS:\\lib\\rustlib\\etc\\libstd.natvis" "/ENTRY:main" "/MERGE:.edata=.rdata" "/MERGE:.rustc=.data" "/MERGE:.rdata=.text" "/MERGE:.pdata=.text" "/DEBUG:NONE" "/EMITPOGOPHASEINFO"
      = note: some arguments are omitted. use `--verbose` to show all linker arguments
      = note: libcompiler_builtins-b938875b878c1ff4.rlib(compiler_builtins-b938875b878c1ff4.compiler_builtins.c7542ed34b4d2950-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol fmaf referenced in function _ZN83_$LT$f32$u20$as$u20$compiler_builtins..math..libm..support..float_traits..Float$GT$3fma17hb07370d428c712a6E␍
              libcompiler_builtins-b938875b878c1ff4.rlib(compiler_builtins-b938875b878c1ff4.compiler_builtins.c7542ed34b4d2950-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol fma referenced in function _ZN83_$LT$f64$u20$as$u20$compiler_builtins..math..libm..support..float_traits..Float$GT$3fma17h158ba5f14d8cf5fbE␍
              C:\Users\lander\dev\solstice\crates\shellcode_stage1_network\target\x86_64-pc-windows-msvc\release\deps\shellcode_stage1_network.exe : fatal error LNK1120: 2 unresolved externals␍
    

    I may have missed something but I couldn't really find any other recent similar issues in compiler_builtins or this repo.

    The failing project is here (note: I have not pushed changes yet for the extern crate workaround and a different issue that surfaced by upgrading nightly): https://github.com/exploits-forsale/solstice/blob/main/crates/shellcode_stage1_network/Cargo.toml
20. apiraino

    removed

    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}Issue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}

    on Mar 31, 2025
21. tgross35 commented on Apr 1, 2025

    

    tgross35

    on Apr 1, 2025

    Member

    More actions

    @landaire that shouldn't be related to the change here, mind opening a new issue?