Compiling `no_std` for `i686-pc-windows-gnu` ignores `panic=abort`

[Irate-Walrus]

When cross-compiling a #![no_std] crate for i686-pc-windows-gnu with panic=abort it includes unwinding symbols and its dependencies:

Archive member included to satisfy reference by file (symbol)

/usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o)
                              /home/irate-walrus/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/rsbegin.o (__register_frame_info)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defs01135.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (abort)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defs01177.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (free)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defs01228.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (malloc)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defs01234.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (memcpy)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defs01279.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (strlen)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defh.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defs01135.o) (_head_lib32_libmsvcrt_def_a)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_deft.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(libmsvcrt_defh.o) (_lib32_libmsvcrt_def_a_iname)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-tlsmcrt.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (_CRT_MT)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32s01416.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (_imp__Sleep@4)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32s00996.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (_imp__LeaveCriticalSection@4)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32s00898.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (_imp__InitializeCriticalSection@4)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32s00321.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/libgcc_eh.a(unwind-dw2-fde.o) (_imp__EnterCriticalSection@4)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32h.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32s01416.o) (_head_lib32_libkernel32_a)
/usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32t.o)
                              /usr/lib/gcc/i686-w64-mingw32/13-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32h.o) (_lib32_libkernel32_a_iname)

As panic=abort is specified in the crate's Cargo.toml I would expect that these dependencies would not be linked. This would also be consistent with the behavior when compiling for x86_64-pc-windows-gnu which does not link these symbols.

I have also attempted the compilation of the crate using the Z build-std=core,alloc,panic_abort -Z build-std-features=panic_immediate_abort flags which as not resolved this issue. I also define my own panic-handler and other required symbols in the main.rs. Previous discussion on the rust-lang forum can be found here: https://users.rust-lang.org/t/inclusion-of-lkernel32-and-others-when-compiling-no-std-for-i686-pc-windows-gnu/121551/14.

The project can be found here: https://github.com/Irate-Walrus/stardust-rs .

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (b8c8287a2 2024-11-03)
binary: rustc
commit-hash: b8c8287a229cd79604aa84c25e1235fc78cd5f2e
commit-date: 2024-11-03
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3

Backtrace

N/A, the project compiles but due to linkage of additional symbols crashes during runtime with an unrelated error.

[bjorn3]

The target spec for windows-gnu targets hard codes -lgcc_eh:

rust/compiler/rustc_target/src/spec/base/windows_gnu.rs

Line 63 in 2633e01

let static_unwind_libs = &["-lgcc_eh", "-l:libpthread.a"];

[Irate-Walrus]

I believe that these linker flags are passed for both the x86_64-pc-windows-gnu and i686-pc-windows-gnu targets? If so, why does this issue only appear for i686? In addition, despite these libraries being included, it is my understanding that they are discarded/not-linked if none of their symbols are being used.

[mati865]

Maybe it's somehow related to rtstartup files?
https://github.com/rust-lang/rust/tree/master/library/rtstartup

[Irate-Walrus]

There is a lot of symbol similarity there, and it would be included on only i686-pc-windows-gnu. In the project I have -nostartfiles set. So my assumption would be that these shouldn't be included.

[bjorn3]

-nostartfiles stops gcc from passing those object files to the linker. However in the case of rustc, it is rustc itself which passes it's own version of those objects unconditionally. -nostartfiles doesn't have an effect on this.

I wonder if for your purposes compiling for x86_64-unknown-none and using `extern "win64" instead of extern "C" for calling C api's would work.

[Irate-Walrus]

I wonder if for your purposes compiling for x86_64-unknown-none and using `extern "win64" instead of extern "C" for calling C api's would work.

I find this a little confusing as I am attempting to compile for i686 rather than x86_64 in this case. If I were to follow this advice (and it ran), I believe memory address calculations would be incorrect due to the use of usize and extern "win64" calls would fail as the windows APIs would be expecting cdecl or stdcall calling conventions.

-nostartfiles stops gcc from passing those object files to the linker. However in the case of rustc, it is rustc itself which passes it's own version of those objects unconditionally. -nostartfiles doesn't have an effect on this.

Thanks for clearing this up. I assume this is the same behaviour for both x86_64-pc-windows-gnu and i686-pc-windows-gnu targets? In which case this is not causing the issue.