compiler_rt: undefined symbol `_fltused` on uefi targets with hardware floats

[Khitiara]

Zig Version

0.15.0-dev.767+201c0f54a

Steps to Reproduce and Observed Behavior

When compiling a uefi application with hardware floats in the target (generally not ideal practice but still shouldnt error), the following error is returned: error: lld-link: undefined symbol: _fltused. This is intended llvm behavior, and arises due to the use of floats in compiler_rt: https://discourse.llvm.org/t/lld-link-fails-to-link-uefi-binary-because-of-undefined-symbol-fltused/52454

The underlying issue is that uefi is fundamentally a windows-like target, and uefi uses the value of the _fltused symbol to trigger enabling hardware floats and the floating point environment in general, similar to how it is used on windows (for which a conditional export in compiler_rt already exists).

(With softfloats in use, no reference is made to the symbol as hardware float initialization is not required, and ideally no export should be made when softfloats are on.)

Expected Behavior

Compilation to succeed

[alexrp]

It's a pretty easy fix:

zig/lib/compiler_rt.zig

Lines 268 to 270 in 6810ffa

	if (!builtin.link_libc and builtin.os.tag == .windows and (builtin.abi == .none or builtin.abi == .msvc)) {
	@export(&_fltused, .{ .name = "_fltused", .linkage = common.linkage, .visibility = common.visibility });
	}

(See also #21630.)

[Khitiara]

update from further investigation: turns out with softfloats it should still be exported, possibly with a value of 0 instead of 1

[alexrp]

That sounds sus. It's the presence of _fltused that has an effect, not its value.

https://github.com/llvm/llvm-project/blob/79108da325daec08f5b50169a9c35e03ea0645a3/llvm/lib/Target/X86/X86AsmPrinter.cpp#L1052-L1071

[Khitiara]

That sounds sus. It's the presence of _fltused that has an effect, not its value.

https://github.com/llvm/llvm-project/blob/79108da325daec08f5b50169a9c35e03ea0645a3/llvm/lib/Target/X86/X86AsmPrinter.cpp#L1052-L1071

possible, ive seen it referred to either way; im not sure if the symbol's value is actually checked anywhere in the runtime (and for that matter, if uefi is being emitted as windows as a workaround, if its even required on efi targets for that matter or if this is just an issue of llvm seeing windows and inserting the reference)

[alexrp]

We lower the target triple *-uefi-msvc to *-windows-msvc currently, so that's why LLVM ends up inserting references to _fltused. Until LLVM gains first-class UEFI support (maybe in 21 or 22), we should just export _fltused for UEFI under the same conditions as we do for Windows to prevent link errors. It has no real effect anyway since there's no MSVC CRT.