From nobody Sat Aug 31 17:43:06 2024 X-Original-To: freebsd-arm@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 4Wx2Rv4XjDz5MmFT for ; Sat, 31 Aug 2024 17:43:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wx2Rv1sm7z4SGD for ; Sat, 31 Aug 2024 17:43:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725126200; bh=UWErIHNtXIRF0nCZ6L/pJOn6hvaqSWSpIfCGERlyGkI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=frhqNViSaJoHyf4cmKQ7WIS0BWgjPS70YyRjwU1FFTWeYhPbDIyZRIcaSxkd8wrDc2fqyR2WovJHFOM7kfcYEisDDljZGBr/bVWapn02Wv0WCIZl1m8fWktzRYJWAUyvZ77Q1BpaBCJq3lzh28iKAGXUDwAungzJlhqw6+vkCbCinHLdlpiujc2cqJJG1/ksxWKJrTCWhRegWoOKSBXYPrvelPblrmfzzvxZhBqlZENH/KtOLXLHZJL7y0E3QXX1ud0x754wGGPtwa2f7YLmSJf7hidzZ2AWHxujqYGa+nnRFqih/YpcLT+ChBu3NHvbmCKo3RhwsVCeqlB36r+ucw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725126200; bh=Xp3ZczZpxy215q4PR/HG6LbqSbH1Oqu4QbPk+Miz3Im=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N/ZxBz0BgQMbmMBTBV+f+YsISC76G6EjTMzgIg60QFlgpoau2/bGLwXwcNsbL3LJALl33BgiR4hyGa9PLqK8D2mJf1u4dG1jvkO7VAKFKes8udY6XD/Y/5Uz8LZ4hZZ4a5fIqA7RqTpiOWykWcuhW7gzM2EkVlpEWShhUIVFvnJ8K32KFYwZcQENQRuBDmAbNrKrnVX8cSH9rb9McZBvE8xqE+69OqWrlXMGKx1Zeh1yMxw7etMP4Ve/RXuixqm0KkczS6MO8Og6o2w5qoY+dJ15in94JjDRmIljCvr56SslkVnzkys+4//J+neUBuX1WBwzk83/ZzcTTWWjiN8JtA== X-YMail-OSG: AewTWqwVM1mhqUKP8SUXscvru2rXRmpRaBner5oOVr.yvfyixcvVkFbGVtKHXYM 1nDwzCjMvCh.jtA34AvI1jkvsE_.K28j7SXENhtJKR8J5ct9MvhYR80Y9cMWy_mOw7MeUvJXPTQJ f2JhZmMx7aKLygJDy0Ecwcqyi.3YlU94KM8PQ9YqU0tsxOgrv.mWAPnjRK1.uTHuYhl01E2VEHhr 14ADaEQiH37nzyHitsMXkdOArwaAjkYS6ZgT8rti4VL6odDR38garJf8fqRyHBT4eBD6d8VvqHiZ i.zDMVU3UWlk9b4lnAkOKhmkZwPnfWyCcgGUUr4PoWFPTgE03sgxhu0PzsNiWQrNTXR385NEHsYM JOeyjAQwtpzlwyTKBZUIrjgoDE_t5ogxkXHG5FTfEirc3f.QtFDymXllc5ubSWEXJJUC0RGptvWK hRPHVwK1jJdR37TCGEQ4BKs.saSSkGVacioeb2eNeVGXAXSI0zeAg6AY9YxQo9Xa92okY4YIRuJ9 wugR2Tw0JtuyptiogCj3oDMg1RwJGTauirjARoS9gir8R6P6ucYE.CfQoK0L3pyOHOOYDTKNdGaH cs_jyMGfhArueiZ9uTL4m1hDNTPMolurMhlajmbXprino_4Izu6mUyA3V12MzVN5e_fqOx7DfqAY ygvGAN5NmdXVuqZhK3FowaFeprCsXv2XvjQe9pU0KtzVZoj0Jz4BYXDUoAFkVSDvpR.frcPN.0Uf WnzpKKABfrLLyqQTQ.53XdUEgMAvozrJ0GAFleoOtNN0vQesLmYtSIaG_LSmSvmoqyFLKy2_BNHF tw.kwdf1MghcRPvFvG891vlqRAPUrS6mfP0JhWrIwho9DVeIwjATem_vL.4eRGaGdo.Ioi2D1pzP xv36F7GmhvH_l_.GnTGZeXzodkMSbmaaxK8oOIukhkIZQqHbqnaV50Qh7onv.mEHCMS6fMnJj_in BAWiS3rMcAvzgF3ywj_VcvF8wVc.YS7nK_eKUjwlY4OGrG9kKoOuv220Ad43w6Z8qL9mpY0H4o8f S.FU.UUyno4bX..pw9IKaPXX1nEK8L7Yc26LJXbNgraqI2Mn4XdmRenmbE6yRls7JKjzrvwvZFGe bA0PNRpQloPb64k5tuE27dXy.e68KMjEoC1ILUlDbFC7CZMGyQb3gZFgF3eFCSF_RD.bILyoE3DS KRQcAqbvE.7r5JIiEgn0plZ3S01CQnZlpSyU9xCcQvgneFgowLSAaNcUR0VOThFho7dxzl.g3iVd JP08L3yEgBjSvtETVs5og212k5BbtML7VYGPpYIoXt9pWXTG6qEbytG1DY9AW0sg4S_Leu4E9AVF Hjqfo6vq8bvzNk9bcXD6Hx7.sWHiXElz98FK2bZdsN8gmP4xGaBjt2OXPf1XykBBsfnnkOlmyCbm p_fw1n_.Rz_frn9QIjjJ.nBYm4UZTJsu_VDNmzCjkfJfoa5OvR4QB_kpiw4coFhE6414zplA2qUm KObTydH3r46iKfoHa1uA94peIz2hgBO7B_z5yWqO4rY.ZYcivWbpEHPldSZOv.o6GKy9X4FO.q4p BREDXytFj1I6iRbHnj7tOV9nnOyY_8RSsSYxrPdcrmXeigJ985dxabFmB9fQiae9DGPrAdYLvoS4 8NHyOGo3XWtlyx.5oedo73g68izU0Xve09CtJVnu4EC2wZ0IrT27ZJjqiazoXkltTsuG6whHSWoL ADwjBsx7xTdqnecCUKia7MLo.8qfUcKTajafVesBXSxUe_hvqg_bUeUouIu4v15nh3ix611lKgCU o_6VWy_fcr3XWKdY0OzgwEQql5d0ZtgvNUTZNLlArldfTqvqTqyGDHWzrKk_qKey22tRWoe2NMMs 2t9dUN062w3i8cJYTT1YsGx1SZHiGHMR2cSPsVDLEYW4Gh7IaOvzbUV9F4y75xd.z3mrdGHyr4.I cPa7YIblvNWgdoM7Csx5aXHWsEqUTN9GHdnjo5.o.aACz9.mhPlBBUc5XYM6FfrbhaQ89Wu49Qk6 N2hMscvHrolxvFHzWDkZVxzCVJCfV49BfS9alUULYdV.tfNcNjF_W4WE4nF53vXsKldF4n5OKajH AZywrMc_7zhH91hV_ino.IQE5gkcY3Y9ZjzalpssWd.sQ6PrMLsw1PW8dUaoTiCxHT_yK6YJRqzq 1UC30dpd16aTUGmciOGBHtxEd7kAW8mJwKkTja1ePYfdYwJVzy2uXLScUPpEu49PdlYlgYnftsS8 hBMTS3CsRgYuZ0WoXIgX4XOdYEyxYWuMkO6800aA3OkaVgopuRP20VZ0IO3NPoFQ7nkeCIa3S4jU tMp2s1.y6cBpm4zGtTIqwwCrYwIiLSzuwkMkcKb0ziyJu9GQ- X-Sonic-MF: X-Sonic-ID: 1851c1ca-05c8-4897-8b29-a76850338684 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 17:43:20 +0000 Received: by hermes--production-gq1-5d95dc458-5n5gs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b32315c11689c559c0d6a891fd9d2fac; Sat, 31 Aug 2024 17:43:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: For an armv7 context, /usr/local/llvm1[789]/lib/clang/1[789]/include/arm_bf16.h does not exist: one thing blocking a firefox build via llvm1[78] From: Mark Millard In-Reply-To: <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> Date: Sat, 31 Aug 2024 10:43:06 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Wx2Rv1sm7z4SGD On Aug 31, 2024, at 00:16, Michal Meloun wrote: > On 31.08.2024 8:29, Mark Millard wrote: >> On Aug 30, 2024, at 22:05, Mark Millard wrote: >>> On Aug 30, 2024, at 21:26, Mark Millard wrote: >>>=20 >>>> On Aug 30, 2024, at 20:33, Mark Millard wrote: >>>>=20 >>>>> [Subject was retitled.] >>>>>=20 >>>>> On Aug 30, 2024, at 16:24, Mark Millard wrote: >>>>>=20 >>>>>> What my test-of-building got was: No include file = found and >>>>>> no OFlags::TMPFILE found (OFlags:: was found, TMPFILE in OFlags:: = was not): >>>>>>=20 >>>>>> In file included from = /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.c:43: >>>>>> In file included from = /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.h:3434= : >>>>>> /usr/local/llvm17/lib/clang/17/include/arm_neon.h:37:10: fatal = error: 'arm_bf16.h' file not found >>>>>> 37 | #include >>>>>> | ^~~~~~~~~~~~ >>>>>> . . . >>>>>>=20 >>>>>> error[E0599]: no associated item named `TMPFILE` found for struct = `backend::fs::types::OFlags` in the current scope >>>>>> --> = /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti= x/src/backend/libc/fs/syscalls.rs:144:32 >>>>>> | >>>>>> 144 | if oflags.contains(OFlags::TMPFILE) && = crate::backend::if_glibc_is_less_than_2_25() { >>>>>> | ^^^^^^^ associated item not = found in `OFlags` >>>>>> | >>>>>> ::: = /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti= x/src/backend/libc/fs/types.rs:203:1 >>>>>> | >>>>>> 203 | / bitflags! { >>>>>> 204 | | /// `O_*` constants for use with [`openat`]. >>>>>> 205 | | /// >>>>>> 206 | | /// [`openat`]: crate::fs::openat >>>>>> ... | >>>>>> 333 | | } >>>>>> 334 | | } >>>>>> | |_- associated item `TMPFILE` not found for this struct >>>>>> | >>>>>> . . . >>>>>> =3D note: this error originates in the macro = `$crate::__impl_bitflags` which comes from the expansion of the macro = `bitflags` (in Nightly builds, run with -Z macro-backtrace for more = info) >>>>>>=20 >>>>>> . . . >>>>>>=20 >>>>>> error[E0599]: no associated item named `TMPFILE` found for struct = `backend::fs::types::OFlags` in the current scope >>>>>> --> = /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti= x/src/backend/libc/fs/syscalls.rs:207:32 >>>>>> | >>>>>> 207 | if oflags.contains(OFlags::TMPFILE) && = crate::backend::if_glibc_is_less_than_2_25() { >>>>>> | ^^^^^^^ associated item not = found in `OFlags` >>>>>> | >>>>>> ::: = /wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti= x/src/backend/libc/fs/types.rs:203:1 >>>>>> | >>>>>> 203 | / bitflags! { >>>>>> 204 | | /// `O_*` constants for use with [`openat`]. >>>>>> 205 | | /// >>>>>> 206 | | /// [`openat`]: crate::fs::openat >>>>>> ... | >>>>>> 333 | | } >>>>>> 334 | | } >>>>>> | |_- associated item `TMPFILE` not found for this struct >>>>>> | >>>>>> . . . >>>>>> =3D note: this error originates in the macro = `$crate::__impl_bitflags` which comes from the expansion of the macro = `bitflags` (in Nightly builds, run with -Z macro-backtrace for more = info) >>>>>>=20 >>>>>> . . . >>>>>> =3D note: this error originates in the macro = `$crate::__impl_bitflags` which comes from the expansion of the macro = `bitflags` (in Nightly builds, run with -Z macro-backtrace for more = info) >>>>>>=20 >>>>>> For more information about this error, try `rustc --explain = E0599`. >>>>>> error: could not compile `rustix` (lib) due to 2 previous errors >>>>>>=20 >>>>>>=20 >>>>>> For reference: >>>>>>=20 >>>>>> # uname -apKU >>>>>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #8 = main-n271819-5cbb98c8259c-dirty: Fri Aug 23 22:06:47 PDT 2024 = root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src= /arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500023 1500023 >>>>>>=20 >>>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports/ >>>>>> 87a38a839ab8 (HEAD -> main, freebsd/main, freebsd/HEAD) = net-im/dissent: update package description >>>>>> Author: Jan Beich >>>>>> Commit: Jan Beich >>>>>> CommitDate: 2024-08-24 18:30:01 +0000 >>>>>> branch: main >>>>>> merge-base: 87a38a839ab83c2def100a0975a7afb29e873cf2 >>>>>> merge-base: CommitDate: 2024-08-24 18:30:01 +0000 >>>>>> n674987 (--first-parent --count for merge-base) >>>>>>=20 >>>>>> But firefox was updated to use: nss>=3D3.103:security/nss to = match what was >>>>>> available. >>>>>=20 >>>>>=20 >>>>> Using devel/llvm18 instead got the same. >>>>>=20 >>>>> Looking inside even a /usr/local/llvm19/lib/clang/19/include/ >>>>> also shows the arm_bf16.h file is not present. By contrast, >>>>> for an aarch64 context: >>>>>=20 >>>>> # file /usr/local/llvm19/lib/clang/19/include/arm_bf16.h >>>>> /usr/local/llvm19/lib/clang/19/include/arm_bf16.h: C source, ASCII = text >>>>>=20 >>>>> Looking quickly at more llvm* shows: >>>>>=20 >>>>> # grep -r arm_bf16 /usr/ports/devel/llvm1*/ | more >>>>> = /usr/ports/devel/llvm11/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%= %LLVM_RELEASE%%/include/arm_bf16.h >>>>> = /usr/ports/devel/llvm12/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%= %LLVM_RELEASE%%/include/arm_bf16.h >>>>> = /usr/ports/devel/llvm13/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%= %LLVM_RELEASE%%/include/arm_bf16.h >>>>> /usr/ports/devel/llvm14/Makefile:_BE_INCS_ARM=3D = arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>>> /usr/ports/devel/llvm15/Makefile:_BE_INCS_ARM=3D = arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: = `arm_sve.h` and `arm_bf16.h`, and all those generated files will contain = a >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: = `arm_bf16.h` immediately before their own typedef: >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: = #include >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: = Since `arm_bf16.h` is very likely supposed to be the one true place = where >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << = "#include \n"; >>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS << = "#include \n"; >>>>> /usr/ports/devel/llvm16/Makefile:_BE_INCS_ARM=3D = arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h >>>>> /usr/ports/devel/llvm17/Makefile:_BE_INCS_AArch64=3D = arm_bf16.h arm_sme_draft_spec_subject_to_change.h >>>>> /usr/ports/devel/llvm18/Makefile:_BE_INCS_AArch64=3D = arm_bf16.h >>>>> /usr/ports/devel/llvm19/Makefile:_BE_INCS_AArch64=3D = arm_bf16.h >>>>>=20 >>>>> llvm1[456] had _BE_INCS_ARM containing arm_bf16.h (and more). >>>>> llvm1[789] do not. >>>>>=20 >>>>> I wonder if: >>>>>=20 >>>>> = https://cgit.freebsd.org/ports/commit/devel/llvm17/Makefile?id=3D778e212f2= 34a825c5e19612df4be2e8f838cb024 >>>>>=20 >>>>> doing: >>>>>=20 >>>>> -_BE_INCS_ARM=3D arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h = arm_neon.h arm_sve.h >>>>> +_BE_INCS_ARM=3D arm_cde.h arm_fp16.h arm_mve.h arm_neon.h = arm_sve.h >>>>>=20 >>>>> was correct. I'll note that in an armv7 context: >>>>>=20 >>>>> # find /usr/local/*/gcc14/ -name arm_bf16.h -print >>>>> = /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd15.0/14.2.0/include/arm_bf16= .h >>>>>=20 >>>>> suggesting that gcc14 considers the file as not aarch64 specific = but >>>>> as armv7 compatibile. >>>>=20 >>>> I got that wrong! arm vs. aarch64 have different source files with = the >>>> same name (under different paths): >>>>=20 >>>> gcc/gcc/config/arm/arm_bf16.h has guard test: #ifndef = _GCC_ARM_BF16_H >>>> gcc/gcc/config/aarch64/arm_bf16.h has guard test: #ifndef = _AARCH64_BF16_H_ >>>>=20 >>>> (More content is different.) >>>=20 >>> As for llvm*: >>>=20 >>> clang/lib/Basic/Targets/ARM.cpp has: >>>=20 >>> if (HasBFloat16) { >>> Builder.defineMacro("__ARM_FEATURE_BF16", "1"); >>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1"); >>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1"); >>> } >>>=20 >>> clang/lib/Basic/Targets/AArch64.cpp has: >>>=20 >>> if (HasBFloat16) { >>> Builder.defineMacro("__ARM_FEATURE_BF16", "1"); >>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1"); >>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1"); >>> } >>>=20 >>> which suggests bf16 support has 32-bit support (even if it is armv8 >>> 32-bit). Looking for AArch32 state in: >>>=20 >>> DDI0487K_a_a-profile_architecture_reference_manual.pdf >>>=20 >>> it says (via the AArch32 column of a table): >>>=20 >>> BF16 Supported if FEAT_AA32BF16 is implemented. >>>=20 >>> Looks to me like the removal of arm_bf16.h for llvm target ARM >>> was incorrect. >>>=20 >>>>> So I've put arm_bf16.h back into the llvm18 test context and = sometime >>>>> after 3 hrs I should be able to report on a firefox build attempt = with >>>>> the change (I hope). >>>>=20 >>>=20 >> So, it no longer failed for amd_bf16.h being missing. >> But it still has the lack-of OFlags::TMPFILE problem that stops the = build. >=20 > See > = lang/rust/files/armv7/patch-vendor_rustix_src_backend_libc_fs_syscalls.rs > for inspiration. Unfortunately the exact patch depends on the rustx = version, which changes a lot at this place. As far as I can tell, for rust conditional compilation with the likes of (leading whitespace details might not have been preserved): #[cfg(all(unix, target_env =3D "gnu", not(any(target_os =3D = "freebsd", target_os =3D "hurd"))))] if oflags.contains(OFlags::TMPFILE) && = crate::backend::if_glibc_is_less_than_2_25() { return openat_via_syscall(dirfd, path, oflags, mode); } is not just textual preprocessing like #if . . . #endif in C/C++. It seems that the conditional source still gets some validation processing even though it will not generate any code. If so, the error report indicates that freebsd is not getting a definition of the likes of OFlags::TMPFILE . I do not know if freebsd should have a definition of OFlags::TMPFILE (and related) vs. not. If the definition should be present, the problem is not local to the 2 blocks of code that are rejected. If the definition should not be present, then the technique for handling freebsd for armv7 is not valid and the fix might also not be local to the 2 blocks of code. As I'm only trying to see if my armv7 builds can finish based on the limited effective process address space size, at some point I'll likely locally adjust the patching to cause "if false {" or some such that avoids the validation checking's rejection. I have no intention of running firefox --and I have no armv7 video context set up to do so. =3D=3D=3D Mark Millard marklmi at yahoo.com