Undefined symbols when linking `i686-unknown-uefi` without using `-Zbuild-std`

[nicholasbishop]

Simple repro:

# rust_toolchain.toml
[toolchain]
channel = "nightly"
targets = ["i686-unknown-uefi"]

// src/main.rs:
#![no_main]
#![no_std]

#[panic_handler]
fn panic_handler(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[export_name = "efi_main"]
pub extern "C" fn main(_h: *mut core::ffi::c_void, _st: *mut core::ffi::c_void) -> usize {
    panic!();
}

Compile with cargo build --target i686-unknown-uefi. This fails with undefined symbols ___udivdi3 and ___umoddi3.

Full output

   Compiling tmp-i686-test v0.1.0 (/var/home/nbishop/src/tmp-i686-test)
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: "rust-lld" "-flavor" "link" "/NOLOGO" "/entry:efi_main" "/subsystem:efi_application" "/tmp/rustcf3Esr7/symbols.o" "/var/home/nbishop/src/tmp-i686-test/target/i686-unknown-uefi/debug/deps/tmp_i686_test-e070b2b3d9570a0b.4r7w5v2t9imd2qsu.rcgu.o" "/LIBPATH:/var/home/nbishop/src/tmp-i686-test/target/i686-unknown-uefi/debug/deps" "/LIBPATH:/var/home/nbishop/src/tmp-i686-test/target/debug/deps" "/LIBPATH:/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-uefi/lib" "/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-uefi/lib/librustc_std_workspace_core-87aa5ecf680885c4.rlib" "/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-uefi/lib/libcore-078ea958aaba8579.rlib" "/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-uefi/lib/libcompiler_builtins-a6f227741d962a9d.rlib" "/NXCOMPAT" "/LIBPATH:/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-uefi/lib" "/OUT:/var/home/nbishop/src/tmp-i686-test/target/i686-unknown-uefi/debug/deps/tmp_i686_test-e070b2b3d9570a0b.efi" "/OPT:REF,NOICF" "/DEBUG" "/NODEFAULTLIB"
  = note: rust-lld: error: undefined symbol: ___udivdi3
          >>> referenced by /rustc/e75aab045fc476f176a58c408f6b06f0e275c6e1/library/core/src/num/dec2flt/decimal.rs:126
          >>>               libcore-078ea958aaba8579.rlib(core-078ea958aaba8579.core.3b584330-cgu.0.rcgu.o):(core::num::dec2flt::decimal::Decimal::left_shift::hdaf1b75087ea64fb)
          >>> referenced by /rustc/e75aab045fc476f176a58c408f6b06f0e275c6e1/library/core/src/num/dec2flt/decimal.rs:137
          >>>               libcore-078ea958aaba8579.rlib(core-078ea958aaba8579.core.3b584330-cgu.0.rcgu.o):(core::num::dec2flt::decimal::Decimal::left_shift::hdaf1b75087ea64fb)
          >>> referenced by /rustc/e75aab045fc476f176a58c408f6b06f0e275c6e1/library/core/src/num/flt2dec/strategy/dragon.rs:295
          >>>               libcore-078ea958aaba8579.rlib(core-078ea958aaba8579.core.3b584330-cgu.0.rcgu.o):(core::num::flt2dec::strategy::dragon::format_exact::h6e53ee3200af73e2)
          >>> referenced 40 more times
          
          rust-lld: error: undefined symbol: ___umoddi3
          >>> referenced by /rustc/e75aab045fc476f176a58c408f6b06f0e275c6e1/library/core/src/fmt/num.rs:501
          >>>               libcore-078ea958aaba8579.rlib(core-078ea958aaba8579.core.3b584330-cgu.0.rcgu.o):(core::fmt::num::parse_u64_into::h6ca2586fb1d1d6c4)
          >>> referenced by /rustc/e75aab045fc476f176a58c408f6b06f0e275c6e1/library/core/src/fmt/num.rs:502
          >>>               libcore-078ea958aaba8579.rlib(core-078ea958aaba8579.core.3b584330-cgu.0.rcgu.o):(core::fmt::num::parse_u64_into::h6ca2586fb1d1d6c4)
          >>> referenced by /rustc/e75aab045fc476f176a58c408f6b06f0e275c6e1/library/core/src/fmt/num.rs:503
          >>>               libcore-078ea958aaba8579.rlib(core-078ea958aaba8579.core.3b584330-cgu.0.rcgu.o):(core::fmt::num::parse_u64_into::h6ca2586fb1d1d6c4)
          >>> referenced 2 more times

Interestingly, the error does not reproduce when using -Zbuild-std. Compiling with cargo build --target i686-unknown-uefi -Zbuild-std=core,compiler_builtins is successful.

Meta

rustc --version --verbose:

rustc 1.67.0-nightly (e75aab045 2022-11-09)
binary: rustc
commit-hash: e75aab045fc476f176a58c408f6b06f0e275c6e1
commit-date: 2022-11-09
host: x86_64-unknown-linux-gnu
release: 1.67.0-nightly
LLVM version: 15.0.4

[nicholasbishop]

@rustbot claim

[nicholasbishop]

It looks like there are two issues here, which I will start working on PRs for.

The first issue is that we aren't setting clang as the C compiler used when disting the UEFI targets. Presumably it's just defaulting to gcc, with the end result that C code gets compiled into ELF objects instead of PE. You can see this by running objdump -t path/to/libcompiler_builtins.rlib, which will show a mix of formats like:

compiler_builtins-c71194a2c8a54b35.compiler_builtins.86fabcdc-cgu.0.rcgu.o:     file format pe-x86-64
[...]
compiler_builtins-c71194a2c8a54b35.compiler_builtins.86fabcdc-cgu.1.rcgu.o:     file format pe-x86-64
[...]
absvdi2.o:     file format elf64-x86-64
[...]
absvsi2.o:     file format elf64-x86-64
[...]

This mix of formats doesn't cause an error until you actually try to use one of the functions in an ELF object, at which point you'll get a linker error.

The second issue relates to compiler_builtins using optimized assembly for some builtins: https://github.com/rust-lang/compiler-builtins/blob/0.1.83/build.rs#L302. When clang compiles these asm files, it doesn't add a @feat.00 symbol like it does for C files, so we get SEH errors from the linker. There doesn't seem to be any flag to change that behavior, so the simplest solution for now is probably to modify compiler_builtins to not add the .S files for any UEFI target.

Edit: the @feat.00 could be added with -Wa,-defsym,@feat.00=1, but then we'd need a way to only pass that flag for asm targets. Filed a cc feature request for that: rust-lang/cc-rs#751

[nicholasbishop]

The necessary fixes in compiler_builtins have been made and released in 0.1.84. Next step is #104561