From nobody Mon May 26 13:24:32 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b5c1Z1Q0Vz5xlbm for ; Mon, 26 May 2025 13:24:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b5c1Z0frWz3x1l; Mon, 26 May 2025 13:24:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748265874; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1BZM9GL0F16+po4bNsrmumPbqolk1TC8+iRr5ymSJlU=; b=v8H/nRPxRiJiYlj6DbjEafk2GTlVay42D00sR4j+QjQ4c1s5NL7u9zykHa6onSbbYeckyM AumMCi9ytY+bA/hLuqETagrwW909mXxtlakykVQkxthrn1RApiW53mn0GjJxsLgvzrZUm4 yPIjSbT2n6XLKKMRvZtm+qmbU2EwB516fJCbvs6gvfPiH3+qTLyRwDBqhV131xJz0tAJAZ VXib0vp1bd7b1A9PI/7u5rRouhgxUxdY9RJVlzZ109/i86sfvYuJkwCUK+NGUK6VCs4THE 4yWFijnGcMyj/DDkWRgeEpYnunS2WdujGRd4YSmXTJEiCBc/e7ZkTv8CyL6eoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1748265874; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1BZM9GL0F16+po4bNsrmumPbqolk1TC8+iRr5ymSJlU=; b=bHvmY/g4t6pyClawxXVrXu8PjAE92gy7oUJ1yzniCeqxPNuxQ4Gjpsf0Lfk9aTgWhr8Xwg 586FSEQyUJAYAOlbmwdzOtDRWSID2WNj2HZI2XtyynAEnGEdbvU76IFZh0l1zYnVmbUDDL MEpQ2lnr+Cvehb4xevG+XXPowEYsoW5QU8OaBx0VkdEcpEQhL5ca8vLbv0fWw/jv+B9yuR GSMmJKxmiilJilZFeZ/9k5HjsJD2zPURdLUwhNxJ2tT7xTbd5c97AR7Khr3aBQFrHG60Gz cJIE+df5T/GpS0HFfVdaccwUXfVekDNYJ4vcoRYXJIk4s0PMEIia1vRAQsDKKg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1748265874; a=rsa-sha256; cv=none; b=EdJh3N5HwO7/7kFXyd0HArBMeh24ACdvcUNTm8sxwN9+s4URaRUtgutlR8J8gsF9ZsL0SS ZGSlJLXJsLe0DlsHO553PKbIPpoWRsGcrFE0WXN2eAc4WbpUweXjfJXwBTGPR69tpTnoZ7 soGt+yxwLoDN2jsGznJqTzQ6pzZBaK0AsQGEXM8EzVrUbFY/XteNScs6YW3lOSbdwBOQZn Ik7OA+uCz8I4zuzT82cRCTQLnd4ixKH9OINdMQzxfq14oo8ssl7/Z8aVgFRn6llTZPo9c7 KS6mo70epE8uje9qURQAMhBdwJJRxSSyUsoVDctHu7uiyY/atMWkTTmmahRSdg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R11" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b5c1Y6SM5z10NQ; Mon, 26 May 2025 13:24:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 00CB341300; Mon, 26 May 2025 15:24:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.11\)) Subject: Re: (arm64) link_elf: symbol __floatundidf undefined ... From: Dimitry Andric In-Reply-To: Date: Mon, 26 May 2025 15:24:32 +0200 Cc: "current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0r5n4p87-3pn0-3247-8n6q-n20qn0ro27r9@yvfgf.mnoonqbm.arg> <74650476-D42E-4074-A18F-D7F474EC271B@FreeBSD.org> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3731.700.6.1.11) On 26 May 2025, at 15:15, Dimitry Andric wrote: >=20 > On 26 May 2025, at 15:05, Bjoern A. Zeeb = wrote: >>=20 >> On Mon, 26 May 2025, Dimitry Andric wrote: >>=20 >> Hi, >>=20 >> thanks for the quick answer. >>=20 >>> On 26 May 2025, at 14:25, Bjoern A. Zeeb = wrote: >>>>=20 >>>> I've just compiled and installed a new arm64/main with my own = kernel >>>> config to have wifi bits as modules. >>>>=20 >>>> I am a bit puzzed as to where this comes from in the kernel. >>>>=20 >>>> # kldload wlan >>>> link_elf: symbol __floatundidf undefined: 0xffff000143ed1370 = 0xffff000143ecf9f0 11496 0xffff000143ed26d8 0x2 >>>> kldload: can't load wlan: No such file or directory >>>>=20 >>>> % nm modules/usr/src/sys/modules/wlan/wlan.ko.full | grep float >>>> U __floatundidf >>>>=20 >>>> Anyone any idea? >>>=20 >>> _Something_ is converting a unsigned long to a double, but what? Can = you figure out which object file it is? >>=20 >> % nm ieee80211_ioctl.o | grep __floatundidf >> U __floatundidf >>=20 >> This may be a local change I have adding an extra 10% of space in the >> ioctl code to accomodate for enlargement of a result set for testing. >> size_t space; >> ... >> space *=3D 1.10; >>=20 >> Given it's likely that it's that I think the real question is, why is = this >> not an issue on amd64 but on arm64 as I've been running that change = for >> days on amd64? >=20 > My guess is that it's inlined on amd64. For me simple cases also = inline on arm64, but maybe you are doing something more complicated: >=20 > $ cat convert.c > #include >=20 > size_t f(size_t s) > { > return s * 1.10; > } >=20 > $ cc -target aarch64-freebsd -S convert.c -o - > .text > .file "convert.c" > .section .rodata.cst8,"aM",@progbits,8 > .p2align 3, 0x0 // -- Begin = function f > .LCPI0_0: > .xword 0x3ff199999999999a // double = 1.1000000000000001 > .text > .globl f > .p2align 2 > .type f,@function > f: // @f > .cfi_startproc > // %bb.0: // %entry > sub sp, sp, #16 > .cfi_def_cfa_offset 16 > str x0, [sp, #8] > ldr d0, [sp, #8] > ucvtf d0, d0 > adrp x8, .LCPI0_0 > ldr d1, [x8, :lo12:.LCPI0_0] > fmul d0, d0, d1 > fcvtzu x0, d0 > add sp, sp, #16 > .cfi_def_cfa_offset 0 > ret > .Lfunc_end0: > .size f, .Lfunc_end0-f > .cfi_endproc > // -- End function > .ident "FreeBSD clang version 19.1.7 = (https://github.com/llvm/llvm-project.git = llvmorg-19.1.7-0-gcd708029e0b2)" > .section ".note.GNU-stack","",@progbits > .addrsig Aha, the behavior changes when you use -mgeneral-regs-only (as in = https://cgit.freebsd.org/src/tree/sys/conf/kern.mk#n140): f: // @f .cfi_startproc // %bb.0: // %entry stp x29, x30, [sp, #-16]! // 16-byte Folded Spill .cfi_def_cfa_offset 16 mov x29, sp .cfi_def_cfa w29, 16 .cfi_offset w30, -8 .cfi_offset w29, -16 bl __floatundidf mov x1, #-7378697629483820647 // =3D0x9999999999999999 movk x1, #39322 movk x1, #16369, lsl #48 bl __muldf3 bl __fixunsdfdi .cfi_def_cfa wsp, 16 ldp x29, x30, [sp], #16 // 16-byte Folded Reload .cfi_def_cfa_offset 0 .cfi_restore w30 .cfi_restore w29 ret Hence, try to refrain from using doubles. :) Your use case should also = be covered with: space =3D (space * 110 + 50) / 100 -Dimitry