@log2 implementation missing in CrossCompile for Cortex-M4 (Thumb)

Hi! I’m trying to cross-compile for cortex-m4 (FPU onboard).
The test code is meaningless:

    fn computeDutyCycle(self: *Led, duty: f32) void {
        const sqrt = @sqrt(duty);
        const log2 = @log2(duty);
    }

My corss-build tuning is:

    var cpu_features = std.Target.Cpu.Feature.Set.empty;
    cpu_features.addFeature(@intFromEnum(std.Target.arm.Feature.vfp4d16sp));

    const arm_cm4_target = CrossTarget{
        .cpu_arch = .thumb,
        .os_tag = .freestanding,
        .cpu_model = .{
            .explicit = &.{
                .name = "cortex_m4",
                .llvm_name = "cortex-m4",
                .features = .{ .ints = .{0} ** 5 },
            },
        },
        .cpu_features_add = cpu_features,
        .abi = .eabihf,
    };
    const target = b.resolveTargetQuery(arm_cm4_target);

And in the end, the function looks well, it really utilizes basic FPU instruction set:

Disassembly of section .text:

20003090 <main.Led.computeDutyCycle>:
20003090: b580         	push	{r7, lr}
20003092: 466f         	mov	r7, sp
20003094: b084         	sub	sp, #0x10
20003096: 9000         	str	r0, [sp]
20003098: ed8d 0a01    	vstr	s0, [sp, #4]
2000309c: eeb1 1ac0    	vsqrt.f32	s2, s0
200030a0: ed8d 1a02    	vstr	s2, [sp, #8]
200030a4: f008 fc18    	bl	0x2000b8d8 <__Thumbv7ABSLongThunk_log2f> @ imm = #0x8830
200030a8: ed8d 0a03    	vstr	s0, [sp, #12]
200030ac: b004         	add	sp, #0x10
200030ae: bd80         	pop	{r7, pc}

But when it comes to the log2 calculations, it just sends me to hell:


Disassembly of section .text:

2000b8d8 <__Thumbv7ABSLongThunk_log2f>:
2000b8d8: f240 0c01    	movw	r12, #0x1
2000b8dc: f2c0 0c00    	movt	r12, #0x0
2000b8e0: 4760         	bx	r12

do I miss some feature in build.zig? By the way, everything is compiled in Debug mode.

hmm… I’m afraid to be wrong, but it looks like zig compiler populates the object file with all these “doors to hell” (_Thumbv7ABSLongThunk*) at compile time, so there is no way to link against a static archive with all that math stuff from, say, arm’s toolchain…

I don’t know either it is an option, but looks like it is better to fail the build at link stage, rather than allow LLVM to populate object file with messy code in the absence of libc/libm

Any sugessions?