From nobody Tue Dec 3 07:38:23 2024 X-Original-To: freebsd-toolchain@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 4Y2XZp0f2Dz5g0CG for ; Tue, 03 Dec 2024 07:38:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4Y2XZm5GKPz4LxD for ; Tue, 3 Dec 2024 07:38:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NU8uIr2g; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733211518; bh=Xo8+DOHDSrz3a1aQZ171HlAju+6znOxPxYfNKu5j/54=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NU8uIr2gGPUGDMOCr29qb/xDMPIKTx40vIYD5AzJ9lYaUJXmAwxcb0x9v6Zmd3nvfB4bm8A7Jx2eOW0eumRYdXZ5klUgVmK5iz9WW2LGR4mYbW3aS7IWv1MXbzwBqkraYS7njg/3KX233GxmrpFT8ddciFlfrQZp+UP58ZpWnvZwasnMhV1OLjtsU+n4jzMBscrJS/CdPpd3JaX6BRVB4EFjZXTr76PiI5/Xf+tnHQycbcfsIlYx47ZDtka7CfYHIG5+4inHXif7J7yBj2uBotftjlitMr0IC1GhPmI9TEL8UFM6kT1sd8d3HbNL1YGUVsm9IJdNh2QgFBTm41t54A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733211518; bh=/3YIqsY0jG6VvYEhJVPHDZosj+UgSg/tT1jsmoNSk1q=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G2TwK7l9YKnX8jqBUjGO2wX3nD5tVj8mtCOze7Esk6qsLKsLBeHCaJihTS9Xg0whcS4E/xuPKj6NF87eRO/0caMWUW5JcOjwDEEVBvZ2e8oPvjU9eDILdKlrR+T/pnOh3T2OkPnmYB9lS7ubXJEWpqnZU5o8HTdpO0woL3C6Vx2yP6YxNEZQDboA2SemTH0gGlzOkwzjbSpvRFp4UirG9YvvwoPLHZ/eW+B5cWiRMYvwNqbgxfEgE1o6xjR8ZGYNgwwiWkKPaDiFSENiDTgKicwfB2NYhxFtVUG8jMWyMV2ZlM1yUs3bbxyEmkVGqiNI8uL0q3oRwyuwCQiQtgE8aQ== X-YMail-OSG: CojYWFkVM1kb_otZDMI06zp6Ypbbj_MDnwuu73exu.V0uVbQ68_NQHK5I8Yz9Il 1Dq6vvCGaZBSVnONIQojcMvp5uUVPK2ygwKmhyM5WAv6K9q8gfRPb3OjZa3OFfKV3x_MA09iuelE ml8UpV_4F_YINT24kvVAL12YqnGycL_KObz.AHoEepFjLO7bdTpIxl8C5kVIIeXQW9W.QNeU7WML MzK24iN32Nj839sj3ppaS_XRUXAPUDqtWqZkM3kY_a3AUhchSHhVl2VoZR6eKSKQbRiui4g78H6l M7VDxBQArcAoZHIojF1GYpAlohIfeiaLTn6aCuvV93t8MezJ4P2.6y6XyLMrI8DhfmVH4CtDVn6q 4pZqWI0FKmDuED60ZVw.qDEoehx5qjODdg9d4Er2btpoQrz_PyLbtpQoY81JPZEFnV51yvlTbJ8g vqLP9q29fOZun31i.B9kszZodYIogj_68OBHzpHH4ClkoGMzqY4Lc5MwcAAkhoxm2wNlcpJrkf8K GJ6HDRleTiJtpA_WNhBqkMG_evTsxkf8dbUc1p7PEX54ph.y3ebkzIoY_mkg1eH3PigDhE8Vr7KY 8u5ftJL8neu.Mx3.tQHJtlSdd5mf0aQOa.1D375f9nJ1Q5w1pw_n1gTTo8vxM8KLvJIUfSvAwUXz ywFGU8HB8Bs0PAp2IRUlf1Jl6dkzOhIXngcxIipHBSQo3GblU.X3EWGIU2zILGd82ELcza.SdiOx uBv6jW3nC96QzdBd8Ii3nfUslXneYiNpfZV.mnRhslK1OX0wnKDVmFmoIOsU2tzjYtMxMrdWe8Fu rfF9aHDlO.lK0oSvV5A3dyliuFd54WIwAamTjlV8S0HfS7kV5hjfkVCNo5ZfQtyXfQLkDuB2jFe1 3uWw_OqH0ypK.La2_i99JamakZo.zBeydVE7tGfM8.UtEsRIVoujDLrun0197zwVbdUOQNoIQ.Cg J4v8yDuWJ5SZ522n7IBfdrLdPSxN9VTyMXCQCvzIod4uKEjTwcgVtctj0COUlJ2JyCnFd2lAZnpl mRfAt7e51zJu0NBeeduX4ULsy_.YOltBomm1oXHemE.31nRPNf95TrYI4frFZKDwwpq00QIB.4Ui sDOzsfsec579QTTCD_40Z67KYTWPJriy9FXC54goRzOyqBfdB_CGqDTdD2ys4otTIpNVrervH3.y K47i626qWbMSnd4NL.c3DZbSu9xO6ipkTMcISiryVywQPZN346.myKorehwSP_ZfS5RqrZb_Lq5A UstLkV3SgwG15ZwEj9Q4Q6jFm5fNkrUaZ8NpZ.GPuaGgK2kG2QKDfUI9skhcJK3XeRK2AMwwCOKN y7Xqr5mHxF6stqLV.jWL.ie6IfXupOx6gXLa2uWhyW_etdk69X7BmGnE0dv1hCG0XbuUCzrM1ggx Z0VUnsPbyjniqHVp0IqNVb_wuPYzwkCiMHu3ksmsjiN57I05SRzRseKsd_j9w0gLh2_flAHffJxA l.HNFPFdKmonWNQJVfHJ5_CMdcsehnKzd7EoXki6iEcqydGmMioDaX2T9p85luMGmAMIBMnv5nrW 7Qyt_hwc8udTfrwIkd6JOFYwU_M3tuO0OkpocjbLJDoMHk23zJR.cdU.XJzlxbisZVvjMAOOHluq Kgydk5RKsA6PUVP_jAkYhtkvcJZJyUJOEniPb6oqwSvGrSTVjxmyI_P_6dWF6ResS2Zc_jFyw_8u _ykNUvQGg6ihARXl_ni.Uh28m2thD20ISenhlePijTab9m.dqAeQ5oBCuoTP1fn.YyvAGd_NxUng OowpfrkAXugDvietOqfbXgUZlBzkeix0Uzim7ZIZ3JAu_.ZkecRVMlIpnXiFt8Lv1CrdGrF.61iE f9EdY57F4FRUKYrJYSBj1_R4ThlSAheDPkP42Cj0ExiMGJRLx1axnjSHcwyyAtihmKwEfLXlDke4 Fo.v5IRteRfjjZ6MECmwQD3b_8fcITvPsOdXQj6Y7Sub_KzX9OQwEx_7Q8y2Z4JLjWsP05cg7XJ0 DhD7NRlNY6ngO5Oso8fMSY.WDobO1c_KTHYloaEVaC31XvMPMjuZ9YAbxBIKsjj2z_e.3mzX8IB6 wh1hNr7ppqgZCCNiN3DObFn68zpKHEteoAIZz2fsQX400gZ.QT_7SLqaXeVEWY55TweFzCBtIymZ 5ElSM.nJXo6wNK_BBcKxT4Yh5GU0BLnk5whi_6mComD_chq72gvFiYM1NbaBS6MxgnsIn8t81DMz R5kTte0wzBKBVcuWcdeJ83_FnHYQn9RTaFZyb5reY6pftutXUKD8bNSSvs7b3JAFo3LSCxtDXkFU x_rMFhw80lGTA8lE532I- X-Sonic-MF: X-Sonic-ID: 904e45d7-df2d-4cd6-9a03-87ae31bf858a Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Dec 2024 07:38:38 +0000 Received: by hermes--production-gq1-5dd4b47f46-ps69l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c601e501aa9c2cd0acecd24331934546; Tue, 03 Dec 2024 07:38:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> Date: Mon, 2 Dec 2024 23:38:23 -0800 Cc: FreeBSD ARM List , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4Y2XZm5GKPz4LxD X-Spamd-Bar: --- Top post of identifying a new context: Now that stable/14 is based on LLVM19, stable/14 is broken like main [so: 15] was, at least in part. Some MFC activity looks to be required in order to boot armv7 via stable/14 now. More may be required. The failure looks like: . . . mmc1: on aw_mmc1 mmc1: No compatible cards found on bus aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 mmc2: on aw_mmc0 mmcsd1: 32GB at mmc2 = 50.0MHz/4bit/32768-block mmc2: Failed to set VCCQ for card at relative address 43690 uhub0: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered uhub5: 1 port with 1 removable, self powered uhub8: 1 port with 1 removable, self powered Root mount waiting for: usbus3 Fatal kernel mode data abort: 'Alignment Fault' on write trapframe: 0xc6b7dc10 FSR=3D00000801, FAR=3Ddb0b901b, spsr=3D20000013 r0 =3Ddb0b9000, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 r4 =3Ddb058c80, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 r8 =3Dc6b7dd20, r9 =3Dc0b324fc, r10=3Dc08ef8dc, r11=3Dc6b7dcb8 r12=3D00000000, ssp=3Dc6b7dca0, slr=3Dc019f774, pc =3Dc019f524 panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc6b7d970 FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 r0 =3Dc6b7da24, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7db1c, r11=3Dc6b7da18 r12=3Dc6b7dad8, ssp=3Dc6b7da00, slr=3Dc0665720, pc =3Dc066974c panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc6b7d6f0 FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 r0 =3Dc6b7d7a4, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d89c, r11=3Dc6b7d798 r12=3Dc6b7d858, ssp=3Dc6b7d780, slr=3Dc0665720, pc =3Dc066974c panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc6b7d470 FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 r0 =3Dc6b7d524, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d61c, r11=3Dc6b7d518 r12=3Dc6b7d5d8, ssp=3Dc6b7d500, slr=3Dc0665720, pc =3Dc066974c After that the L1 translation fault repeats over and over. On Nov 8, 2024, at 04:49, Michal Meloun wrote: > On 08.11.2024 4:15, Mark Millard wrote: >> [I narrowed the artifact kernel range for the change in the type of >> failure that happens.] >> On Nov 7, 2024, at 17:43, Mark Millard wrote: >>> [The change to LLVM 19 is what leads to the Alignment >>> Fault' on write failure. Details later below.] >>>=20 >>> On Nov 7, 2024, at 01:42, Mark Millard wrote: >>>=20 >>>> Note: Unfortunately, the panics here are too early for a >>>> dump device to be available. >>>>=20 >>>> Context started PkgBase upgrade from: >>>>=20 >>>> # uname -apKU >>>> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>>>=20 >>>> Installed packages to be UPGRADED: >>>> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] >>>> FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-src-sys: 15.snap20241011221604 -> = 15.snap20241106160110 [base] >>>>=20 >>>> (Those were installed but the FreeBSD-dtb had linux 6.4 >>>> dtb files, not the 6.8 ones. 6.8 ones from a personal build >>>> were copied to where they need to be. I've separately >>>> reported the 6.4 vs. 6.8 issue.) >>>>=20 >>>> # ~/pkgbase-snapshot-list.sh >>>> Via pkg-static info -C -x '^FreeBSD-' . . . >>>> 1 FreeBSD-*-15.snap20241106160110 >>>> 6 FreeBSD-*-15.snap20241106134422 >>>> 1 FreeBSD-*-15.snap20241028121139 >>>> 3 FreeBSD-*-15.snap20241011221604 >>>> 2 FreeBSD-*-15.snap20241011210446 >>>> 38 FreeBSD-*-15.snap20241011182434 >>>> 4 FreeBSD-*-15.snap20241011073851 >>>> 5 FreeBSD-*-15.snap20241010141501 >>>> 1 FreeBSD-*-15.snap20241010120743 >>>> 296 FreeBSD-*-15.snap20241009161500 >>>> Instead via /var/cache/pkg/*.snap*.pkg . . . >>>> 1 FreeBSD-*-15.snap20241106160110 >>>> 6 FreeBSD-*-15.snap20241106134422 >>>> 1 FreeBSD-*-15.snap20241028121139 >>>> 10 FreeBSD-*-15.snap20241011221604 >>>> 2 FreeBSD-*-15.snap20241011210446 >>>> 38 FreeBSD-*-15.snap20241011182434 >>>> 4 FreeBSD-*-15.snap20241011073851 >>>> 5 FreeBSD-*-15.snap20241010141501 >>>> 1 FreeBSD-*-15.snap20241010120743 >>>> 297 FreeBSD-*-15.snap20241009161500 >>>>=20 >>>>=20 >>>> The failure (kernel-GENERIC-NODEBUG): >>>>=20 >>>> . . . >>>> Root mount waiting for: usbus3 CAM >>>> Fatal kernel mode data abort: 'Alignment Fault' on write >>>> trapframe: 0xc6c9ac10 >>>> FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 >>>> r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 >>>> r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 >>>> r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 >>>> r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 1 >>>> time =3D 3 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) >>>> sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>> pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) >>>> sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 >>>> r4 =3D 0x00000100 r5 =3D 0x00000000 >>>> r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 >>>> vpanic() at vpanic+0x140 >>>> pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) >>>> sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 >>>> r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 >>>> r6 =3D 0xdb23209b r7 =3D 0x00000001 >>>> r8 =3D 0x00000801 r9 =3D 0x00000013 >>>> r10 =3D 0xdb23209b >>>> vpanic() at vpanic >>>> pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) >>>> sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 >>>> r4 =3D 0x00000001 r5 =3D 0x00000801 >>>> r6 =3D 0x00000013 r7 =3D 0xdb23209b >>>> r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 >>>> r10 =3D 0xc6c9ab1c >>>> abort_align() at abort_align >>>> pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) >>>> sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 >>>> r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b >>>> abort_align() at abort_align+0x70 >>>> pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) >>>> sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 >>>> r4 =3D 0x00000000 r10 =3D 0xdb23209b >>>> abort_handler() at abort_handler+0x430 >>>> pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) >>>> sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 >>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>> r10 =3D 0xc092074c >>>> exception_exit() at exception_exit >>>> pc =3D 0xc0669868 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>> sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 >>>> r0 =3D 0xdb232080 r1 =3D 0x00000000 >>>> r2 =3D 0x00000006 r3 =3D 0x00000024 >>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>> r10 =3D 0xc092074c r12 =3D 0x00000000 >>>> bbb_command_start() at bbb_command_start+0x4c >>>> pc =3D 0xc01aff88 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>> sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 >>>> r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 >>>> r6 =3D 0x00000001 r10 =3D 0xc092074c >>>> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >>>> pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 = (usb_alloc_device+0x9c4) >>>> sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 >>>> r4 =3D 0x00000000 r5 =3D 0x00000001 >>>> r6 =3D 0x00000000 r7 =3D 0x00000002 >>>> r8 =3D 0xdb16d800 r9 =3D 0xda241c78 >>>> r10 =3D 0x000003ee >>>> usb_alloc_device() at usb_alloc_device+0x9c4 >>>> pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) >>>> sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 >>>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>>> r6 =3D 0xdb16e800 r7 =3D 0x00000000 >>>> r8 =3D 0xdb18c200 r9 =3D 0x00000001 >>>> r10 =3D 0x00000000 >>>> uhub_explore() at uhub_explore+0x494 >>>> pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) >>>> sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 >>>> r4 =3D 0xda241c78 r5 =3D 0xdb16e800 >>>> r6 =3D 0x00000000 r7 =3D 0xda241d6c >>>> r8 =3D 0xc09b0b5f r9 =3D 0x00000001 >>>> r10 =3D 0xda241d1c >>>> usb_bus_explore() at usb_bus_explore+0x1d4 >>>> pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) >>>> sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 >>>> r4 =3D 0xda241d0c r5 =3D 0xda241d14 >>>> usb_process() at usb_process+0x124 >>>> pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) >>>> sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 >>>> r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 >>>> r6 =3D 0xc6d08740 r7 =3D 0xda241d0c >>>> r8 =3D 0xc01b21ac r9 =3D 0x00000000 >>>> r10 =3D 0x00000000 >>>> fork_exit() at fork_exit+0xb0 >>>> pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) >>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>> r4 =3D 0xc01b21ac r5 =3D 0xda241d0c >>>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>>> r8 =3D 0x00000000 r10 =3D 0x00000000 >>>> swi_exit() at swi_exit >>>> pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) >>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>> KDB: enter: panic >>>> [ thread pid 14 tid 100069 ] >>>> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >>>> db> >>>=20 >>> Using just available official artifact kernels for testing >>> I've established that 0953460ce149 (and various from before >>> that) does not have the problem: >>>=20 >>> Wed, 23 Oct 2024 >>> =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb >>> =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu >>> =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu >>> =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu >>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" Baptiste Daroussin >>> =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin >>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" John Baldwin >>> =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests = in fmemopen(3) Ed Maste >>>=20 >>> So the above one worked. >>>=20 >>> The next available kernel to test was f3dbef108212 (the bump for = LLVM19 >>> at the end of the below): >>>=20 >>> =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard >>> =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in = new fmemopen test Ed Maste >>> =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric >>> =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric >>> =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric >>> =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D = 19, similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric >>> =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in = ath_hal's ar9002 Dimitry Andric >>> =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric >>> =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric >>> =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: = avoid using long long functions if not supported, even for older = compilers that do not support the using_if_exists attribute. Dimitry = Andric >>> =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric >>> =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric >>> =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric >>> =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric >>> =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric >>> =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric >>> =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric >>> =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric >>> =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric >>> =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric >>> =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric >>> =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install = headers that were reintroduced by reverts Dimitry Andric >>> =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric >>> =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric >>> =E2=80=A2 git: 62987288060f - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric >>> =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric >>> =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 = from llvm git (by Nikolas Klauser): Dimitry Andric >>> =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric >>> =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project = release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric >>> =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project = release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric >>> =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for = llvm 19.1.2 merge Dimitry Andric >>>=20 >>> f3dbef108212 gets the: >>>=20 >>> "Fatal kernel mode data abort: 'Alignment Fault' on write" >>>=20 >>> boot failure for artifact kernel. 6b9f7133aba4 does nit >>> seem a likely source of the problem, basically leaving the >>> LLVM changes as what is at issue. >>>=20 >>> I'll note that artifact kernels are witness kernels. So >>> this exploration adds to the distinctions observed >>> compared to the prior notes. >>>=20 >>>> Looking at bbb_command_start() 's pc: >>>>=20 >>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >>>> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>>>=20 >>>> What leads to that line is: >>>>=20 >>>> = /*------------------------------------------------------------------------= * >>>> * bbb_command_start - execute a SCSI command synchronously >>>> * >>>> * Return values >>>> * 0: Success >>>> * Else: Failure >>>> = *------------------------------------------------------------------------*= / >>>> static int >>>> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t = lun, >>>> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >>>> usb_timeout_t data_timeout) >>>> { >>>> sc->lun =3D lun; >>>> sc->dir =3D data_len ? dir : DIR_NONE; >>>> sc->data_ptr =3D data_ptr; >>>> sc->data_len =3D data_len; >>>> sc->data_rem =3D data_len; >>>> sc->data_timeout =3D (data_timeout + USB_MS_HZ); >>>> sc->actlen =3D 0; >>>> sc->error =3D 0; >>>> sc->cmd_len =3D cmd_len; >>>> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>>>=20 >>>> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >>>=20 >>> The below looks to be a separate problem based on >>> some later FreeBSD kernel update than the above. >>>=20 >>>> I'll note that attempting to use the WITNESS variant of the kernel >>>> ( /boot/kernel/ ) gets a different, even earlier failure: >>>>=20 >>>> . . . >>>> VT: init without driver. >>>> panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>=20 >>> I do know that d021d3b3c675 at the end of the below >>> shows this failure --before the system has a chance >>> to get the usb related write alignment failure >>> reported above. >>>=20 >>> I have not explored where in the below range the >>> behavior changes (for what is available as an >>> official artifact kernel). It seems unlikely that >>> any of the below would actually boot: it is likely >>> a question of which of the 2 (or more) failure >>> types happen for each instead. >> The last before "Thu, 24, Oct 2024" was: >> =E2=80=A2 git: 8b2e7da70855 - main - llvm19: permit = incremental builds from llvm18 Brooks Davis >> That is the last available artifact kernel that gets the >> original usb related write alignment type of failure. >>> Thu, 24 Oct 2024 >>> =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore >>> =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov >>> =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov >>> =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov >>> =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit = masks definitions for LAM in %cr3 Konstantin Belousov >>> =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit = masks definitions for EFER features Konstantin Belousov >>> =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit = masks definitions for LASS and LAM features Konstantin Belousov >>> =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans >>> =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert = routing statistics to a sysctl Kyle Evans >>> =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling >> The last above is the first available artifact kernel that >> that gets the different error. There are no armv7 artifact >> kernels between 8b2e7da70855 and 77b70ad751df . >> So something from 34951b0b9e78 .. 77b70ad751df leads to >> the change in the type of failure. I've no clue what. >> It looked to me like the x86 commits and e1000 commit had >> no chance of contributing to the armv7 context. Thus >> who I added to the CC vs. did not add. >>> =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans >>> =E2=80=A2 git: 536c8d948e85 - main - intrng: change = multi-interrupt root support type to enum Kyle Evans >>> =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend = on machine/intr.h Kyle Evans >>> =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for = building llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric >>> =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric >>> =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner >>> =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI = priority Andrew Turner >>> =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING = in a data abort Andrew Turner >>> =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable = interrupts when in a spinlock Andrew Turner >>> =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner >>> =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner >>> =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis >>> =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis >>> =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis >>> =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] = and dsp_unit2name() confusion Christos Margiolis >>> =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis >>> =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen >>> =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen >>> =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve = robustness of TRIM handling John Baldwin >>> =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin >>> =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a = stray semicolon Zhenlei Huang >>> =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang >>> =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray = semicolons Zhenlei Huang >>> =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans >>> =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class = with lc_trylock method Gleb Smirnoff >>> =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff >>> =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff >>> =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f14568 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 >>>> r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f141f0 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 >>>> r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f13e78 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 >>>> r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f13b00 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 >>>> r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f13788 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 >>>> r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> . . . >>>>=20 >>>> Looking: >>>>=20 >>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >>>> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>>>=20 >>>> static int >>>> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >>>> { >>>> uma_zone_t zone =3D arg1; >>>> uint64_t cur; >>>>=20 >>>> cur =3D uma_zone_get_frees(zone); >>>> return (sysctl_handle_64(oidp, &cur, 0, req)); >>>> } >>>>=20 >>>> The "return" line is 5676 of sys/vm/uma_core.c . >>>>=20 >>>>=20 >>>> Also, for what leads up to: >>>>=20 >>>> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>>=20 >>>> /* >>>> * The implementation of pmap_fault() uses IN_RANGE2() macro which >>>> * depends on the fact that given range size is a power of 2. >>>> */ >>>> CTASSERT(powerof2(NB_IN_PT1)); >>>> CTASSERT(powerof2(PT2MAP_SIZE)); >>>>=20 >>>> #define IN_RANGE2(addr, start, size) \ >>>> ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - = 1))) >>>>=20 >>>> /* >>>> * Handle access and R/W emulation faults. >>>> */ >>>> int >>>> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, = bool usermode) >>>> { >>>> pt1_entry_t *pte1p, pte1; >>>> pt2_entry_t *pte2p, pte2; >>>>=20 >>>> if (pmap =3D=3D NULL) >>>> pmap =3D kernel_pmap; >>>>=20 >>>> /* >>>> * In kernel, we should never get abort with FAR which is in = range of >>>> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here >>>> * and print out a useful abort message and even get to the = debugger >>>> * otherwise it likely ends with never ending loop of aborts. >>>> */ >>>> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) = { >>>> /* >>>> * All L1 tables should always be mapped and present. >>>> * However, we check only current one herein. For = user mode, >>>> * only permission abort from malicious user is not = fatal. >>>> * And alignment abort as it may have higher = priority. >>>> */ >>>> if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { >>>> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", >>>> __func__, pmap, pmap->pm_pt1, far); >>>> panic("%s: pm_pt1 abort", __func__); >>>> } >>>> return (KERN_INVALID_ADDRESS); >>>> } >>>> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >>>> /* >>>> * PT2MAP should be always mapped and present in = current >>>> * L1 table. However, only existing L2 tables are = mapped >>>> * in PT2MAP. For user mode, only L2 translation = abort and >>>> * permission abort from malicious user is not fatal. >>>> * And alignment abort as it may have higher = priority. >>>> */ >>>> if (!usermode || (idx !=3D FAULT_ALIGN && >>>> idx !=3D FAULT_TRAN_L2 && idx !=3D = FAULT_PERM_L2)) { >>>> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", >>>> __func__, pmap, PT2MAP, far); >>>> panic("%s: PT2MAP abort", __func__); >>>> } >>>> return (KERN_INVALID_ADDRESS); >>>> } >>>>=20 >>>> /* >>>> * A pmap lock is used below for handling of access and R/W = emulation >>>> * aborts. They were handled by atomic operations before so = some >>>> * analysis of new situation is needed to answer the = following question: >>>> * Is it safe to use the lock even for these aborts? >>>> * >>>> * There may happen two cases in general: >>>> * >>>> * (1) Aborts while the pmap lock is locked already - this = should not >>>> * happen as pmap lock is not recursive. However, under pmap = lock only >>>> * internal kernel data should be accessed and such data = should be >>>> * mapped with A bit set and NM bit cleared. If double abort = happens, >>>> * then a mapping of data which has caused it must be fixed. = Further, >>>> * all new mappings are always made with A bit set and the = bit can be >>>> * cleared only on managed mappings. >>>> * >>>> * (2) Aborts while another lock(s) is/are locked - this = already can >>>> * happen. However, there is no difference here if it's = either access or >>>> * R/W emulation abort, or if it's some other abort. >>>> */ >>>>=20 >>>> PMAP_LOCK(pmap); >>>>=20 >>>> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c = . >>>>=20 >>>>=20 >>>> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >>>> kernel.GENERIC-NODEBUG.good/ ) continues to operate >>>> normally. I do not have the older PkgBase kernel/ around >>>> to try, unfortunately. >> I'll remind that this is from using official FreeBSD builds >> of the kernel versions that I tested, not from my personal >> build context. >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com > Hi Mark, >=20 > Please see https://reviews.freebsd.org/D47485 >=20 > Unfortunately, I see 2 problems with llvm 19. >=20 > The first is regression, the compiler generates inline memset() = accessing non-aligned data with sub-optimal instructions (with word = access). This regression triggers bug in the kernel (which should be = fixed in D47485). >=20 > Second, regarding "panic: acquiring blockable sleep lock" is due to an = bug in lld. It mis-links the ".ARM.exidx" section on the output = binary, which is used by the stack unwinder in the kernel. > I don't have a fix for this for now, so you have to use the linker = from llvm18 as a workaround. >=20 > I'm not sure if I have enough free cycles to manage both issues on the = llvm side... =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 5 02:35:24 2024 X-Original-To: freebsd-toolchain@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 4Y3dmF3xJCz5fgKF for ; Thu, 05 Dec 2024 02:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4Y3dmC4JyRz4s7b for ; Thu, 5 Dec 2024 02:35:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WDc2eijt; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733366137; bh=PQH2MSTXNipAouTxwitPbeIrYJiOTDfa6Eb9QtFY6gA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WDc2eijtyLwvswyeIr3HtmYBDI9vZ/aOMU3cXV/N5aAju3/Nb5VXU1O9q9P/qh+JTCH59I27TK7nDinegLAMWL/SyWH7iuD1GvNmEEhm0LkzcoJ1K3Pd7cpiB35EyfMDgaDjc5DLvkZFMDqRuXjjTKeydM9EEAcZ53hY/wwNyr/bQCbiwHbBCUABW+T/K22/Tpa7ajRY6vxFTnAJnk00lDOFsx9+JSq41bEIDo9zJG51PGtCqI6npGFS58kgFD2WGR2YkNCl6Rw+CMH+3GcC54EkAJEgoJfsKJjwvMoPQHFFvxALmvIgO8PLYhscL8XGkh14QC+YfmaO1hW9sno65Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733366137; bh=nHIqGGiuAgK2EO/Tti7T55Z8JXqV4G3NKCcEKPCPqiF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=M48+cC/+Jyz75sAF4ms2JfbXTOTAnq53N5H81rzfPaVbydYUrel7acK1gzSOysFBgJluLh5Vpou0QMAl2rKczbyj8QExq858gZK9lxUosoUx5us/RKhBh5zyiREsV6TSpFCfrGE1ch2o6oL6UGqCOH+2OpsG/gWR8CrJkZv52it5MqSgihR80EwgnLQMvDe42897NgVDkyYjVPY9fvnLPkCqM2daHPfpkjXm8UiVvJR0uNITgLk3QzvAoCN5GUg7vM0670/Uea0LH5QfpzCMyGanRxyCTXiWNT632wlXEVgEweAmBJuntUHLfFXDJg6cuCzMrRXDXTLIN7R97MAUbw== X-YMail-OSG: Nukt9uYVM1mYes30qOlsm.oGPwMnn2IVrfKK.cHaG.cVCKHxriSG.Uiw.UFYma7 DnoqckCGVRUIt3p5YGxd24hEmRNOGyXzlKp32HyqGsyWUaW5G3LWrDQrSkxyGUMyEbQdwleU6WUM 92nYFpu.EG.asbfBqlcWQa12cs6AvPdrHdpKiu3onMmVX.5CgsGpH.1FrxfHuhxwjp.RPbiX5T4n W02t8vJkmLAkIPFyKE1vyT.jvH8X96QLrcL6KdaUZMYq9yFatZp.Sgbm5tHKYp5wC1jpRyIZ01wV mubteGm4IGxFcK4mb8cEiLnTE_8xZi4AkEpDakvcswyTzqaUF3SpYJ5ilo9adPqvlA.qLSyV0fF. lrGnoqn_rrrfQ4Whth5HFtPpvzk_Ug4ldf4S5ksd3fF45o1f0is9bofUv_2IVq3vGHVNEZgCwniM YSHko7G3giFSa6JLUsd9WpAK72NsHQrS_6WtBwirL_4_VLAp2L2N9R7byD57f5PtCmhnXqH1nR31 1eGHFMFs0Fhys8llcRJk_Lh2wRi4JejXozl7VWb.h1tw.bxDcS9u8y6hwCoItuaTk8G4g8tLUhpV SM67ZysDmK7QteRCkfopDgbO3_RSF4JOUALJGwch2EZCftjxDcYUwLkJ4m1JUQRIARQJ4Si77sCQ uZu35tzsAr6kovzEsjCzcItWMWo4KPvf5H4MkyHqk77cAUv1qkocmN203XXORCZ2omdGjkydf_nx .nk0eJ6CDuYW3V2a1rhBewJzROqoXmM6uZFhw6hfZwB4t1E2UZ5M7jvih9qHlJUoUwMcHQE5.Twk guOqQ8RJoLYXMx51yMVmWKfrab_0BXNweHDwtXZ2L9tS.HvbaGuvQ95sloGxx5MRW2e.30egfBhd YjvDUxPkXJdZHr68y.tAUGhR7aE0t3mP7CKTDQzhxuAKbJZQp7x2OJlKE4WQWN6YeyuT6fBx870h w3k5RqYShQ5kSsM_1h8GFX642uG5X9OWHg7MrUWdqf9kcfhE3bIhcIWFqpl..Va.KCtYIDtjIOEb FOuhCpcxNOgKGZTEKCKeUEpBdcTod9r6CyOoIWlApnrVYLCKygGhU.r9Mh4U0HEzar_SnXotJszY AMhhsfS48t8xrZHmhWPmtZ_Bghv1SALS6yNuxLzl9j.BQqopj65ETcY1n9cSaesE.jTkqqNJWBBl X5I4ucoYdS4dHPGPYH0h5_BhkhQEsQi6uVYuzmU76sMmQFn63annr3A96E.MTa9CbTwqxtTCX4Gs K_4K_RtHMg9da1IOEZf5jdMyCl49WTo3h6vEIEPzmolpAI1UJEKoZ1DttZWBv0scfbf_FbceQb9U zEPEBsvCUK8HSEnCOCTCe4nBJ1ngnyvPPfR9lFGcpzdAhB2CFcDibZaBI9CtnmG42SNm7EhbbevB 2Pf9WkpvWFBOCIeoXcAA3X9SINW6yDrI26cH1Fzzl3GF3BAaqOCeuE3m9tJecQjGNsT12GEL2E4Q eakLyPY839KaTI_h0Xk4dZ_wi.Wa8b8sRrO9TYXMNfLtGgC9qBq4Zok33ULM.P60GXH.CcFqnkqY SAnzJ.eEYDN1.uKdDTuHV2inv6fdkdT6l99KS.FV6FMWEGy2v3sJZMyX8sEHJcXQlZqzfzzLOpEj rRGhKzagVU5tJmSmSKxafYW5zthYqGr0JcSTTZuDc6Q2Ycd_ZGS3Ni30D1OMrNBPLLFKw4kW7dSn OsVddVEN47SfPANuLcfogr0kvss2Y9949WldyL6r6y1ObFIjH8cP.rt5EIRBN52dJe4QCiEJHckr 2FJmBV9WfI0dC5oikmVUPFQsV0JBw4RPaWcnEpvjhRtFRoqEd4FnzDQ5AffdkmOXmwINQzMtz16L Wr32OIZWDNsJs9d_heiGSezzyWHNkQtbLqtxv3j5XfbU2KaLdl3UFsyT_nONhsIRTzYQKCQKcVtG YhYAJ0PfWDgeDOzP21Z94TSOlH1HbjmCreXgKLI9_oEam9pTltlzRnvPBKvg3yiWo_24dsRJj5nd Qpsher8SOB2Ns_RM3g6rBt184Ijfi.9YkNjITCEXIpg1oyIoGAP2.P5.25Iurq7OGpjhH7nxPHII z7i5dmoi9MeM.TcAPk84efAcnw3pJSla1N9kATV_nkiRwJcPEeE9IS.BNpiP9W_V97yYuYzy3XyI N98FwEFGNMG93.aeJ2yhC8K0RApzP08bTIrStWZHvMULol7LaRdNOLhNz9BEb1ANDfDTd0LUKIfU qFbrJawB_HzbGglNWATldMiCa1E46xWq3G0ns9H7Sujye6ipO4ayPGRnGE9LMIOzQP2r2ZUj4_OR jVl03X3eWKPCG6Q-- X-Sonic-MF: X-Sonic-ID: 1619e281-9b18-4a00-9271-ec591fc890a5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 5 Dec 2024 02:35:37 +0000 Received: by hermes--production-gq1-5dd4b47f46-5kxd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f50a34fd68b3206006c974e0462a8070; Thu, 05 Dec 2024 02:35:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: Date: Wed, 4 Dec 2024 18:35:24 -0800 Cc: FreeBSD ARM List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <46C557E0-C28A-4562-B5F8-1581DA8805C9@yahoo.com> References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from] X-Rspamd-Queue-Id: 4Y3dmC4JyRz4s7b X-Spamd-Bar: --- On Dec 2, 2024, at 23:38, Mark Millard wrote: > Top post of identifying a new context: >=20 > Now that stable/14 is based on LLVM19, stable/14 is broken > like main [so: 15] was, at least in part. While I've not tested stable/13 for the failure, it also got an update to use LLVM 19 . So likely both of stable/1[34] need updates. > Some MFC activity looks to be required in order to boot armv7 > via stable/14 now. More may be required. Looks to me like the following (that have a mix of MFC wait times: 1 month/4 weeks vs. 1 week) spans the issues in main (and somewhat more: some VFP state corruption issues). * arm: Fix VFP state corruption during signal delivery Michal Meloun 9 = days 1 -18/+24 * arm: link all .rodata variants into one output section Michal Meloun = 2024-11-17 1 -1/+1 * arm: align data section to the supersection. Michal Meloun 2024-11-17 = 1 -3/+1 * arm: add read_frequently, read_mostly and exclusive_cache_line = sections to li... Michal Meloun 2024-11-17 1 -0/+15 * arm: fix symbols around the .ARM.exidx section Michal Meloun = 2024-11-17 1 -0/+1 * arm: Fix typo in ldscript.arm. Michal Meloun 2024-11-17 1 -1/+1 * arm: switch the BUSDMA buffers to normal uncached memory Michal Meloun = 2024-11-11 1 -1/+1 When I looked, it did not seem that any of the 1-week MFCs involved made it into a stable/1[34] yet. > The failure looks like: >=20 > . . . > mmc1: on aw_mmc1 > mmc1: No compatible cards found on bus > aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 >=20 > mmc2: on aw_mmc0 > mmcsd1: 32GB at mmc2 = 50.0MHz/4bit/32768-block > mmc2: Failed to set VCCQ for card at relative address 43690 > uhub0: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > uhub5: 1 port with 1 removable, self powered > uhub8: 1 port with 1 removable, self powered > Root mount waiting for: usbus3 > Fatal kernel mode data abort: 'Alignment Fault' on write > trapframe: 0xc6b7dc10 > FSR=3D00000801, FAR=3Ddb0b901b, spsr=3D20000013 > r0 =3Ddb0b9000, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 > r4 =3Ddb058c80, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 > r8 =3Dc6b7dd20, r9 =3Dc0b324fc, r10=3Dc08ef8dc, r11=3Dc6b7dcb8 > r12=3D00000000, ssp=3Dc6b7dca0, slr=3Dc019f774, pc =3Dc019f524 >=20 > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc6b7d970 > FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 > r0 =3Dc6b7da24, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d > r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 > r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7db1c, r11=3Dc6b7da18 > r12=3Dc6b7dad8, ssp=3Dc6b7da00, slr=3Dc0665720, pc =3Dc066974c > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc6b7d6f0 > FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 > r0 =3Dc6b7d7a4, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d > r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 > r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d89c, r11=3Dc6b7d798 > r12=3Dc6b7d858, ssp=3Dc6b7d780, slr=3Dc0665720, pc =3Dc066974c >=20 > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc6b7d470 > FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 > r0 =3Dc6b7d524, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d > r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 > r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d61c, r11=3Dc6b7d518 > r12=3Dc6b7d5d8, ssp=3Dc6b7d500, slr=3Dc0665720, pc =3Dc066974c >=20 >=20 > After that the L1 translation fault repeats over and over. >=20 >=20 >=20 > On Nov 8, 2024, at 04:49, Michal Meloun wrote: >=20 >> On 08.11.2024 4:15, Mark Millard wrote: >>> [I narrowed the artifact kernel range for the change in the type of >>> failure that happens.] >>> On Nov 7, 2024, at 17:43, Mark Millard wrote: >>>> [The change to LLVM 19 is what leads to the Alignment >>>> Fault' on write failure. Details later below.] >>>>=20 >>>> On Nov 7, 2024, at 01:42, Mark Millard wrote: >>>>=20 >>>>> Note: Unfortunately, the panics here are too early for a >>>>> dump device to be available. >>>>>=20 >>>>> Context started PkgBase upgrade from: >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>>>>=20 >>>>> Installed packages to be UPGRADED: >>>>> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] >>>>> FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-src-sys: 15.snap20241011221604 -> = 15.snap20241106160110 [base] >>>>>=20 >>>>> (Those were installed but the FreeBSD-dtb had linux 6.4 >>>>> dtb files, not the 6.8 ones. 6.8 ones from a personal build >>>>> were copied to where they need to be. I've separately >>>>> reported the 6.4 vs. 6.8 issue.) >>>>>=20 >>>>> # ~/pkgbase-snapshot-list.sh >>>>> Via pkg-static info -C -x '^FreeBSD-' . . . >>>>> 1 FreeBSD-*-15.snap20241106160110 >>>>> 6 FreeBSD-*-15.snap20241106134422 >>>>> 1 FreeBSD-*-15.snap20241028121139 >>>>> 3 FreeBSD-*-15.snap20241011221604 >>>>> 2 FreeBSD-*-15.snap20241011210446 >>>>> 38 FreeBSD-*-15.snap20241011182434 >>>>> 4 FreeBSD-*-15.snap20241011073851 >>>>> 5 FreeBSD-*-15.snap20241010141501 >>>>> 1 FreeBSD-*-15.snap20241010120743 >>>>> 296 FreeBSD-*-15.snap20241009161500 >>>>> Instead via /var/cache/pkg/*.snap*.pkg . . . >>>>> 1 FreeBSD-*-15.snap20241106160110 >>>>> 6 FreeBSD-*-15.snap20241106134422 >>>>> 1 FreeBSD-*-15.snap20241028121139 >>>>> 10 FreeBSD-*-15.snap20241011221604 >>>>> 2 FreeBSD-*-15.snap20241011210446 >>>>> 38 FreeBSD-*-15.snap20241011182434 >>>>> 4 FreeBSD-*-15.snap20241011073851 >>>>> 5 FreeBSD-*-15.snap20241010141501 >>>>> 1 FreeBSD-*-15.snap20241010120743 >>>>> 297 FreeBSD-*-15.snap20241009161500 >>>>>=20 >>>>>=20 >>>>> The failure (kernel-GENERIC-NODEBUG): >>>>>=20 >>>>> . . . >>>>> Root mount waiting for: usbus3 CAM >>>>> Fatal kernel mode data abort: 'Alignment Fault' on write >>>>> trapframe: 0xc6c9ac10 >>>>> FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 >>>>> r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 >>>>> r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 >>>>> r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 >>>>> r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 1 >>>>> time =3D 3 >>>>> KDB: stack backtrace: >>>>> db_trace_self() at db_trace_self >>>>> pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) >>>>> sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>>> pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) >>>>> sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 >>>>> r4 =3D 0x00000100 r5 =3D 0x00000000 >>>>> r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 >>>>> vpanic() at vpanic+0x140 >>>>> pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) >>>>> sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 >>>>> r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 >>>>> r6 =3D 0xdb23209b r7 =3D 0x00000001 >>>>> r8 =3D 0x00000801 r9 =3D 0x00000013 >>>>> r10 =3D 0xdb23209b >>>>> vpanic() at vpanic >>>>> pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) >>>>> sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 >>>>> r4 =3D 0x00000001 r5 =3D 0x00000801 >>>>> r6 =3D 0x00000013 r7 =3D 0xdb23209b >>>>> r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 >>>>> r10 =3D 0xc6c9ab1c >>>>> abort_align() at abort_align >>>>> pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) >>>>> sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 >>>>> r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b >>>>> abort_align() at abort_align+0x70 >>>>> pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) >>>>> sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 >>>>> r4 =3D 0x00000000 r10 =3D 0xdb23209b >>>>> abort_handler() at abort_handler+0x430 >>>>> pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) >>>>> sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 >>>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>>> r10 =3D 0xc092074c >>>>> exception_exit() at exception_exit >>>>> pc =3D 0xc0669868 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>>> sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 >>>>> r0 =3D 0xdb232080 r1 =3D 0x00000000 >>>>> r2 =3D 0x00000006 r3 =3D 0x00000024 >>>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>>> r10 =3D 0xc092074c r12 =3D 0x00000000 >>>>> bbb_command_start() at bbb_command_start+0x4c >>>>> pc =3D 0xc01aff88 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>>> sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 >>>>> r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 >>>>> r6 =3D 0x00000001 r10 =3D 0xc092074c >>>>> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >>>>> pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 = (usb_alloc_device+0x9c4) >>>>> sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 >>>>> r4 =3D 0x00000000 r5 =3D 0x00000001 >>>>> r6 =3D 0x00000000 r7 =3D 0x00000002 >>>>> r8 =3D 0xdb16d800 r9 =3D 0xda241c78 >>>>> r10 =3D 0x000003ee >>>>> usb_alloc_device() at usb_alloc_device+0x9c4 >>>>> pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) >>>>> sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 >>>>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>>>> r6 =3D 0xdb16e800 r7 =3D 0x00000000 >>>>> r8 =3D 0xdb18c200 r9 =3D 0x00000001 >>>>> r10 =3D 0x00000000 >>>>> uhub_explore() at uhub_explore+0x494 >>>>> pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) >>>>> sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 >>>>> r4 =3D 0xda241c78 r5 =3D 0xdb16e800 >>>>> r6 =3D 0x00000000 r7 =3D 0xda241d6c >>>>> r8 =3D 0xc09b0b5f r9 =3D 0x00000001 >>>>> r10 =3D 0xda241d1c >>>>> usb_bus_explore() at usb_bus_explore+0x1d4 >>>>> pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) >>>>> sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 >>>>> r4 =3D 0xda241d0c r5 =3D 0xda241d14 >>>>> usb_process() at usb_process+0x124 >>>>> pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) >>>>> sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 >>>>> r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 >>>>> r6 =3D 0xc6d08740 r7 =3D 0xda241d0c >>>>> r8 =3D 0xc01b21ac r9 =3D 0x00000000 >>>>> r10 =3D 0x00000000 >>>>> fork_exit() at fork_exit+0xb0 >>>>> pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) >>>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>>> r4 =3D 0xc01b21ac r5 =3D 0xda241d0c >>>>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>>>> r8 =3D 0x00000000 r10 =3D 0x00000000 >>>>> swi_exit() at swi_exit >>>>> pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) >>>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>>> KDB: enter: panic >>>>> [ thread pid 14 tid 100069 ] >>>>> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >>>>> db> >>>>=20 >>>> Using just available official artifact kernels for testing >>>> I've established that 0953460ce149 (and various from before >>>> that) does not have the problem: >>>>=20 >>>> Wed, 23 Oct 2024 >>>> =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb >>>> =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu >>>> =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu >>>> =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu >>>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" Baptiste Daroussin >>>> =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin >>>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" John Baldwin >>>> =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests = in fmemopen(3) Ed Maste >>>>=20 >>>> So the above one worked. >>>>=20 >>>> The next available kernel to test was f3dbef108212 (the bump for = LLVM19 >>>> at the end of the below): >>>>=20 >>>> =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard >>>> =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in = new fmemopen test Ed Maste >>>> =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric >>>> =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric >>>> =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric >>>> =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D = 19, similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric >>>> =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in = ath_hal's ar9002 Dimitry Andric >>>> =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric >>>> =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric >>>> =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: = avoid using long long functions if not supported, even for older = compilers that do not support the using_if_exists attribute. Dimitry = Andric >>>> =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric >>>> =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric >>>> =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric >>>> =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric >>>> =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric >>>> =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric >>>> =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric >>>> =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric >>>> =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric >>>> =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric >>>> =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric >>>> =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install = headers that were reintroduced by reverts Dimitry Andric >>>> =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric >>>> =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric >>>> =E2=80=A2 git: 62987288060f - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric >>>> =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric >>>> =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 = from llvm git (by Nikolas Klauser): Dimitry Andric >>>> =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric >>>> =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project = release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric >>>> =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project = release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric >>>> =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for = llvm 19.1.2 merge Dimitry Andric >>>>=20 >>>> f3dbef108212 gets the: >>>>=20 >>>> "Fatal kernel mode data abort: 'Alignment Fault' on write" >>>>=20 >>>> boot failure for artifact kernel. 6b9f7133aba4 does nit >>>> seem a likely source of the problem, basically leaving the >>>> LLVM changes as what is at issue. >>>>=20 >>>> I'll note that artifact kernels are witness kernels. So >>>> this exploration adds to the distinctions observed >>>> compared to the prior notes. >>>>=20 >>>>> Looking at bbb_command_start() 's pc: >>>>>=20 >>>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >>>>> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>>>>=20 >>>>> What leads to that line is: >>>>>=20 >>>>> = /*------------------------------------------------------------------------= * >>>>> * bbb_command_start - execute a SCSI command synchronously >>>>> * >>>>> * Return values >>>>> * 0: Success >>>>> * Else: Failure >>>>> = *------------------------------------------------------------------------*= / >>>>> static int >>>>> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t = lun, >>>>> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >>>>> usb_timeout_t data_timeout) >>>>> { >>>>> sc->lun =3D lun; >>>>> sc->dir =3D data_len ? dir : DIR_NONE; >>>>> sc->data_ptr =3D data_ptr; >>>>> sc->data_len =3D data_len; >>>>> sc->data_rem =3D data_len; >>>>> sc->data_timeout =3D (data_timeout + USB_MS_HZ); >>>>> sc->actlen =3D 0; >>>>> sc->error =3D 0; >>>>> sc->cmd_len =3D cmd_len; >>>>> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>>>>=20 >>>>> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >>>>=20 >>>> The below looks to be a separate problem based on >>>> some later FreeBSD kernel update than the above. >>>>=20 >>>>> I'll note that attempting to use the WITNESS variant of the kernel >>>>> ( /boot/kernel/ ) gets a different, even earlier failure: >>>>>=20 >>>>> . . . >>>>> VT: init without driver. >>>>> panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>>=20 >>>> I do know that d021d3b3c675 at the end of the below >>>> shows this failure --before the system has a chance >>>> to get the usb related write alignment failure >>>> reported above. >>>>=20 >>>> I have not explored where in the below range the >>>> behavior changes (for what is available as an >>>> official artifact kernel). It seems unlikely that >>>> any of the below would actually boot: it is likely >>>> a question of which of the 2 (or more) failure >>>> types happen for each instead. >>> The last before "Thu, 24, Oct 2024" was: >>> =E2=80=A2 git: 8b2e7da70855 - main - llvm19: permit = incremental builds from llvm18 Brooks Davis >>> That is the last available artifact kernel that gets the >>> original usb related write alignment type of failure. >>>> Thu, 24 Oct 2024 >>>> =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore >>>> =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov >>>> =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov >>>> =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov >>>> =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit = masks definitions for LAM in %cr3 Konstantin Belousov >>>> =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit = masks definitions for EFER features Konstantin Belousov >>>> =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit = masks definitions for LASS and LAM features Konstantin Belousov >>>> =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans >>>> =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert = routing statistics to a sysctl Kyle Evans >>>> =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling >>> The last above is the first available artifact kernel that >>> that gets the different error. There are no armv7 artifact >>> kernels between 8b2e7da70855 and 77b70ad751df . >>> So something from 34951b0b9e78 .. 77b70ad751df leads to >>> the change in the type of failure. I've no clue what. >>> It looked to me like the x86 commits and e1000 commit had >>> no chance of contributing to the armv7 context. Thus >>> who I added to the CC vs. did not add. >>>> =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans >>>> =E2=80=A2 git: 536c8d948e85 - main - intrng: change = multi-interrupt root support type to enum Kyle Evans >>>> =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend = on machine/intr.h Kyle Evans >>>> =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for = building llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric >>>> =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric >>>> =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner >>>> =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI = priority Andrew Turner >>>> =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING = in a data abort Andrew Turner >>>> =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable = interrupts when in a spinlock Andrew Turner >>>> =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner >>>> =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner >>>> =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis >>>> =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis >>>> =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis >>>> =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] = and dsp_unit2name() confusion Christos Margiolis >>>> =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis >>>> =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen >>>> =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen >>>> =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve = robustness of TRIM handling John Baldwin >>>> =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin >>>> =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a = stray semicolon Zhenlei Huang >>>> =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang >>>> =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray = semicolons Zhenlei Huang >>>> =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans >>>> =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class = with lc_trylock method Gleb Smirnoff >>>> =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff >>>> =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff >>>> =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f14568 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 >>>>> r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f141f0 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 >>>>> r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f13e78 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 >>>>> r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f13b00 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 >>>>> r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f13788 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 >>>>> r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> . . . >>>>>=20 >>>>> Looking: >>>>>=20 >>>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >>>>> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>>>>=20 >>>>> static int >>>>> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >>>>> { >>>>> uma_zone_t zone =3D arg1; >>>>> uint64_t cur; >>>>>=20 >>>>> cur =3D uma_zone_get_frees(zone); >>>>> return (sysctl_handle_64(oidp, &cur, 0, req)); >>>>> } >>>>>=20 >>>>> The "return" line is 5676 of sys/vm/uma_core.c . >>>>>=20 >>>>>=20 >>>>> Also, for what leads up to: >>>>>=20 >>>>> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>>>=20 >>>>> /* >>>>> * The implementation of pmap_fault() uses IN_RANGE2() macro which >>>>> * depends on the fact that given range size is a power of 2. >>>>> */ >>>>> CTASSERT(powerof2(NB_IN_PT1)); >>>>> CTASSERT(powerof2(PT2MAP_SIZE)); >>>>>=20 >>>>> #define IN_RANGE2(addr, start, size) \ >>>>> ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - = 1))) >>>>>=20 >>>>> /* >>>>> * Handle access and R/W emulation faults. >>>>> */ >>>>> int >>>>> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, = bool usermode) >>>>> { >>>>> pt1_entry_t *pte1p, pte1; >>>>> pt2_entry_t *pte2p, pte2; >>>>>=20 >>>>> if (pmap =3D=3D NULL) >>>>> pmap =3D kernel_pmap; >>>>>=20 >>>>> /* >>>>> * In kernel, we should never get abort with FAR which is in = range of >>>>> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here >>>>> * and print out a useful abort message and even get to the = debugger >>>>> * otherwise it likely ends with never ending loop of aborts. >>>>> */ >>>>> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) = { >>>>> /* >>>>> * All L1 tables should always be mapped and present. >>>>> * However, we check only current one herein. For = user mode, >>>>> * only permission abort from malicious user is not = fatal. >>>>> * And alignment abort as it may have higher = priority. >>>>> */ >>>>> if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { >>>>> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", >>>>> __func__, pmap, pmap->pm_pt1, far); >>>>> panic("%s: pm_pt1 abort", __func__); >>>>> } >>>>> return (KERN_INVALID_ADDRESS); >>>>> } >>>>> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >>>>> /* >>>>> * PT2MAP should be always mapped and present in = current >>>>> * L1 table. However, only existing L2 tables are = mapped >>>>> * in PT2MAP. For user mode, only L2 translation = abort and >>>>> * permission abort from malicious user is not fatal. >>>>> * And alignment abort as it may have higher = priority. >>>>> */ >>>>> if (!usermode || (idx !=3D FAULT_ALIGN && >>>>> idx !=3D FAULT_TRAN_L2 && idx !=3D = FAULT_PERM_L2)) { >>>>> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", >>>>> __func__, pmap, PT2MAP, far); >>>>> panic("%s: PT2MAP abort", __func__); >>>>> } >>>>> return (KERN_INVALID_ADDRESS); >>>>> } >>>>>=20 >>>>> /* >>>>> * A pmap lock is used below for handling of access and R/W = emulation >>>>> * aborts. They were handled by atomic operations before so = some >>>>> * analysis of new situation is needed to answer the = following question: >>>>> * Is it safe to use the lock even for these aborts? >>>>> * >>>>> * There may happen two cases in general: >>>>> * >>>>> * (1) Aborts while the pmap lock is locked already - this = should not >>>>> * happen as pmap lock is not recursive. However, under pmap = lock only >>>>> * internal kernel data should be accessed and such data = should be >>>>> * mapped with A bit set and NM bit cleared. If double abort = happens, >>>>> * then a mapping of data which has caused it must be fixed. = Further, >>>>> * all new mappings are always made with A bit set and the = bit can be >>>>> * cleared only on managed mappings. >>>>> * >>>>> * (2) Aborts while another lock(s) is/are locked - this = already can >>>>> * happen. However, there is no difference here if it's = either access or >>>>> * R/W emulation abort, or if it's some other abort. >>>>> */ >>>>>=20 >>>>> PMAP_LOCK(pmap); >>>>>=20 >>>>> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c = . >>>>>=20 >>>>>=20 >>>>> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >>>>> kernel.GENERIC-NODEBUG.good/ ) continues to operate >>>>> normally. I do not have the older PkgBase kernel/ around >>>>> to try, unfortunately. >>> I'll remind that this is from using official FreeBSD builds >>> of the kernel versions that I tested, not from my personal >>> build context. >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >> Hi Mark, >>=20 >> Please see https://reviews.freebsd.org/D47485 >>=20 >> Unfortunately, I see 2 problems with llvm 19. >>=20 >> The first is regression, the compiler generates inline memset() = accessing non-aligned data with sub-optimal instructions (with word = access). This regression triggers bug in the kernel (which should be = fixed in D47485). >>=20 >> Second, regarding "panic: acquiring blockable sleep lock" is due to = an bug in lld. It mis-links the ".ARM.exidx" section on the output = binary, which is used by the stack unwinder in the kernel. >> I don't have a fix for this for now, so you have to use the linker = from llvm18 as a workaround. >>=20 >> I'm not sure if I have enough free cycles to manage both issues on = the llvm side... >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 6 02:12:21 2024 X-Original-To: toolchain@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 4Y4FBs5NqJz5g66s for ; Fri, 06 Dec 2024 02:12:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4FBs2fv7z438Z for ; Fri, 6 Dec 2024 02:12:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733451141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DEdML6FV656+eX+CUDJnyyDuFlMfDjKBgKf2jnmG/Y0=; b=jSHRhIdK9EVwJbnMjGbLEengXWdCrcxu+QSGEk9xoQox2BGuS3FWBb29coMFKljPNlEmpd ra9oCMr4RE0EJcq2KIyX7ALD/jL0QXipSWpVjMUDx+Gf6CJZ+UsiQaXDLpgt+8nAB/DlJI SV0Ii993AnECPVKSegCV2k4J49iSoFB4DFxtPECJ/S+J77q7GpovXm3GlFnDWDuZ8IGBvM Z55YkPwi/aXzGJ8a9JF0USb9gDZKgqdSbi4iXYYiLw/bu4wc8fPzsAUiRLPOKgI+MwWAmH sMNFVYFlOEJ7oyNMTY1qQ6bDJ0SAoh0ExlQm4QA9CaTaMmEyWO8sWa18iyCtbg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733451141; a=rsa-sha256; cv=none; b=DYvgI6W4HhWSaKwz4mBks3xg8iIfNkZwOogGcBWJs3P7TWzdWJYcIJjn4htuhDFogUeJnD rE7BUgCkRvFkQeBBdFTWHocGO7Sj2QpaZ0j4Vi8trEWfi2lj4TVd7xKcI8krdUWksCAIUW odLGOBNjAXgub9WihPGBp3oesBC59ii36ZWweASxTDR2U+znS0YvyzRziV1sr+aYh8H3oY Dg7JG5ucP5MA1qFs40tRqHYova4SE9C5AoKiwYS55PvCUDiq6MpqVaCcJecLEIT9fV+8ua 6swzBOb1QYLHnM6EZ75JSR9E7prOQ7ALiDIzS6UoMd9y3lqfEbi0q9DUbYlnFQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4FBs24BczJlC for ; Fri, 6 Dec 2024 02:12:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B62CLDc050123 for ; Fri, 6 Dec 2024 02:12:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B62CLqa050122 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 02:12:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 02:12:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yuri@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 Yuri Victorovich changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |toolchain@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 02:57:54 2024 X-Original-To: toolchain@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 4Y4GCQ3mswz5g928 for ; Fri, 06 Dec 2024 02:57:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4GCQ1sx9z48Bd for ; Fri, 6 Dec 2024 02:57:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733453874; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xCd8oGPto/H/xV+zIoY4gqpiQb24DOGMhYRYDQffRNU=; b=Uo0vX5WMNZCCJolz+LP66kCZAyNgB6QKXaKhDKLtQz84Fmj8RKAcxmLGii7nehasbpmL3v Iq/waaVUdnNdwqHG5o60AvURJk2iOZ/0no5OJj0YG71oiaAEgQS7Hi4DmvACW5dtx7Tsee oLpUOMqmSgxRFOcVWFjBgc4jsl4c7u76jZ6+0hyiaRNwl9a1iStQgz73ILYLil9SrBzx1R 2B95m3Gl4IpFICYiGVL4Ueq50fpKcxGdwR7WBBNKTJnxn9ZOGT4hUmip8kLS+KLA0zFTST aWm0ovM5Ps1sKHunwNMVxsjnAEQChyBQ0FAwRyHY4g+WVDK4wpbHGB3GW5qxMQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733453874; a=rsa-sha256; cv=none; b=nqk/4ZpoQwhQXEQ9Q70G7D6xmxpixAIdTf5FXkJ/b1cVVeymDELSLMakuY3tMZSSiNR2Sd Szn8fc6w85aDsVdNkFCwvLkxYgv89LLg32XZwVeSEdvXRetYo3x3tIJnFfVp3Gp9+qbcrG /LcxXLKNeVtjJlWeSMTjOGFbzKNNwhqkBWeaaMxb5Pc0HXcWxdalNLfAsMIEAOTCbyKHBs O8kobik6xgY2FD9eWSzeNoJb3ZeD87YF3szs7QyMmylOZu+W1S3MSa/AsY7SP9/3PyaOXi vsqIv+t3Ip0R4DvTfa4D6OgeXJG5RRBzK+ZdPI7arJ9Orj2+NFs5KRYktUS5KA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4GCQ1NLpzKnM for ; Fri, 6 Dec 2024 02:57:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B62vrYf016318 for ; Fri, 6 Dec 2024 02:57:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B62vrA9016317 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 02:57:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 02:57:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org --- Comment #1 from Ed Maste --- This is an issue with devel/binutils presumably, please indicate the version you are using. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 03:54:50 2024 X-Original-To: toolchain@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 4Y4HT64swqz5gDvw for ; Fri, 06 Dec 2024 03:54:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4HT63Xqjz4FX1 for ; Fri, 6 Dec 2024 03:54:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733457290; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mn3fz+ywIi0AAGb1uSIbESW0hFdVreMX6iKpqHkHsF4=; b=AB+UYXEdetUgiCewtxdC90SxSfOTU+EzmT1PzhcyewXgGOJ1gTt0LqLm+eK0wrls2ZK0mW 7RkHDafIa1Mh87I80I4tek2aGMbThMh31PI+R7B1aQDtuPaCWJU5c+4gQ8V1krZUdtbmxK YvCn7TJv5ZteCk4lkzSggwL/KI1hxSTPRxuYdLz344Z914W0Xre8dxgy30DuKxa7CjbTlj 4XjVxBOCVK1McrJ2YPPncxPpz+PVa+jmuwE9aVyDMbC1aUFio8CQCnGGMGc4mTTq4Ju9bq LPFEQq+hy1waYhMbO3aonto5GVBPWyiKu+CcLpxhB3a69GMPXxOHy+KU8NOMDg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733457290; a=rsa-sha256; cv=none; b=eNVVkHTIp7kfQOV0y625JwGEjP87b9NERF3tF1+HYDuO1P3guK89k0OzHBrmpsLlKDq576 kV0biqHbSD8xw66PK9T9jLN3wsNMxJDkn5X3Qa5sLaJMW6WnZs5woufWk4Wicx+PlWXwoZ PJYzTVBx7DEus+YT1AstmgLfhhYeRVHRGl2NspgHe2rhD1cR0HfAVMFQvwgWL2gmUZoNl7 ULmglUhjM0kBqgXI8ynO2abmEVyvANeZNEiHR9NK+/MA3mox4e7mhtUECG+36vMRvj/6N0 9sea8VpdnPBx/jG2Slx/uJUrUv5cUG6XodvJDUu7YxsRIMMHwgCh0u7FTLBYjA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4HT639FyzLxx for ; Fri, 6 Dec 2024 03:54:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B63soDM011376 for ; Fri, 6 Dec 2024 03:54:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B63soUY011375 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 03:54:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 03:54:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yuri@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #2 from Yuri Victorovich --- (In reply to Ed Maste from comment #1) binutils-2.43.1,1 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 04:10:45 2024 X-Original-To: toolchain@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 4Y4HqV0945z5gFdg for ; Fri, 06 Dec 2024 04:10:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4HqT43LZz4Gpn for ; Fri, 6 Dec 2024 04:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733458245; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uHj4zmjyeGuECvndoGF1suC9ORkh00bJnxgn4yQCrac=; b=JTSnAX3xgu1XWbvYBwcqr8w9cpRwikJot2vApIRpM7SFzDjtdlRybmYc6aajoUwcHg+U3H zKgwUqxjx7wz5ceTAcSNDcQo4slPQpG7OQbmu+/wjZI61b03fzcMMbUUfdYDY6W4qiNG6w O5zkcrs/swDdZpTEUTONLsRjq5gjnYHoMMYLo6FGQ2FwS3RpVFqaQEXi+1ezC26AHP/BcN kYvmkUS4ywd/0OYNha64bovTBZB2keJBspJI1A6rHjqs/abgkbEeBvfvJ75yQq6rkuD7E4 VpV7rQd6vox6ImAGqOPTCU++tDRKmsYnLNExxrNxc5bwO08OCTHJhmGhOgtF7Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733458245; a=rsa-sha256; cv=none; b=Rj1DOMCyzadtxmT/PrPpiC0ehQvVi7lOTQfs/olrOzpL49I3ScyoTw5XlmSjvIdJSktDB9 tgsAa6ha3d5VE0jcly/Y2ya4631Up3dyL7Hkcy0U8QUIqoAJfotO94NJyTFn9w3dj+CqZo EWo4OH9lYvc59Xq6FBKgyc4GllroSAl3MFCPgycF4OJjudYg+aPwRTy9JT094RxTzFg5QY h6NrQbPQIA8WtAItywHQX5JSnKKT2ubkTx6nZakEfoY19ZFzQEsUhsD7T5OQH+fIVs/kM0 Zypk03KkfK/3h8F+iRgP3oxilFZykJlWEY+x7BqssczTrCA1DXzZrYuFMhquhA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4HqT3gnrzMpq for ; Fri, 6 Dec 2024 04:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B64AjHc033695 for ; Fri, 6 Dec 2024 04:10:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B64Ajm7033694 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 04:10:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 04:10:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #3 from Mark Millard --- I explored what happens to exist in my context, which is for main FreeBSD: (I'll note that lang/gcc14 and devel/llvm19 are part of this environment. The system c++ is also LLVM19 based.) # find / -name '*LLVMgold*' -print /usr/local/llvm19/lib/LLVMgold.so # pkg-static info -l llvm19 | grep gold /usr/local/llvm19/lib/LLVMgold.so The system toolchain does not provide LLVMgold.so --and never has if I understand right. # find / -name '*ld.gold*' -print /usr/local/x86_64-portbld-freebsd15.0/bin/ld.gold /usr/local/bin/ld.gold # pkg-static info -l binutils | grep gold /usr/local/bin/ld.gold /usr/local/x86_64-portbld-freebsd15.0/bin/ld.gold # pkg-static which /usr/local/bin/ld.gold /usr/local/bin/ld.gold was installed by package binutils-2.43.1,1 # pkg-static which /usr/local/x86_64-portbld-freebsd15.0/bin/ld.gold /usr/local/x86_64-portbld-freebsd15.0/bin/ld.gold was installed by package binutils-2.43.1,1 # find / -name '*-unknown-*-ld' -print /usr/local/bin/aarch64-unknown-freebsd15.0-ld pkg-static which /usr/local/bin/aarch64-unknown-freebsd15.0-ld /usr/local/bin/aarch64-unknown-freebsd15.0-ld was installed by package aarch64-binutils-2.43.1,1 # pkg info | grep binutil aarch64-binutils-2.43.1,1 GNU binary tools arm-gnueabi-binutils-2.43.1,1 GNU binary tools binutils-2.43.1,1 GNU binary tools # grep -A2 FLAVORS=3D /usr/ports/devel/binutils/Makefile FLAVORS=3D native aarch64 aarch64_none_elf amd64 arm_gnueabi arm_non= e_eabi \ avr i386 mingw32 mips mips64 powerpc powerpc64 powerpc64le riscv64 \ riscv64_none_elf s390x riscv32_unknown_elf So devel/binutils@amd64 seems to be what would supply x86_64-unknown-freebsd*-ld . My context does not happen to have that. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 04:26:43 2024 X-Original-To: toolchain@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 4Y4J9w0S8Dz5gGWF for ; Fri, 06 Dec 2024 04:26:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4J9v6BVwz4J1D for ; Fri, 6 Dec 2024 04:26:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733459203; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lrphwwW1FIUVGn1a8W5qAoFLhgkG0vWR1jhePc+GYV8=; b=ThUYjUDYgZ1cc5dR+vJfZZvJ9Gz65SmQQMrN0v99JMEMDY0v/C+E5FihCqY4CTyWz8FPta e4QqL2bXuvK7tyQv13KV5A+CBYV7TCt/vTfeAgkNCjmJUib1AcIDnUSRwr8By4W03rfYc8 mgDuAtrw3fEU/6yOaNYHNG5kRt9QSzS3xhWp1q/oN/XB4r7zB0cAghWl8wo83j9lcWshOc LJcY9HYIWGw7YoY0lINlS1K1sMawGhMHmcG+JhqF4Fhs+hP8ut84wjoCDePJfdNbOQL4zL zbx3C4oaLTJytgEUsB6bcEpmQXEqns+xElvtFliTeWC7EHgFU4X3zpY40MjlGQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733459203; a=rsa-sha256; cv=none; b=viKNE4Y2Emi21XOfhh3ibg5qOvzUuPZdnIws//XvkWvbPxJalq3DwCScDIVibt3h9ANPIk R17nDF33m5npasphIsamWq/XHlolZbbSHfKnjNTZYf0nTJGNEbFbKueCE2dT5QAJjDqfrj KvZoQPFwwzcDz0uLDFIHW1te/bZu3o1/IVnaqMNBIpWCgOPO1XujXXN23FU5Mpl2cEE74C Pokvp/krMtzR+ZlPvFRhQq6OvQhKENOWwqfyfs0LRfqP4tPsHl8BLvFUnQGvP+TlroZezq IgW94jvHIoNonUwTbgHeRcf4Ey5sU5eLSOWuyMXloRKnQnusupZuykCDE6xYgQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4J9v5hDMzMV3 for ; Fri, 6 Dec 2024 04:26:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B64QhAj068047 for ; Fri, 6 Dec 2024 04:26:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B64QhMX068046 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 04:26:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 04:26:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #3) >From what I can tell, /usr/ports/devel/binutils/Makefile needs to deal with specifying and using a specific version of devel/llvm* in order to use its specific LLVMgold.so . (That note presumes that LLVMgold.so use is really intended, rather than a mistake of its own.) I see no evidence of /usr/ports/devel/binutils/Makefile doing so but it needs to. It may need to track the default devel/llvm* rather than a specific number. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 04:48:22 2024 X-Original-To: toolchain@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 4Y4Jft21Rkz5gHwM for ; Fri, 06 Dec 2024 04:48:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4Jfs6LFvz4KBb for ; Fri, 6 Dec 2024 04:48:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733460501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b3v8C22HCDXy9mIh2d0cftuNhEWlKfNcd8bicukGaJY=; b=pkq1m9Jk2UYYI2ToOgwQqlmLzCqdiVjSt71wjxgbdV77WlP89AaFWsorcU3Vm13SIVCe9q E/3PMDQUDaJcgYYK0PtGla/EtyERWoTGzipA1LB/r77RTlgIWRiiiJCZqv5471BDtbaKlI GQzY2Dc+uavScWpV1DPLBMIhSNLhc15HnxQRx6RmFlkLKxZUxpL5zt5Bt8TMk+d/oTwZ45 b9f/h9DEoo1ltgcSwcEdE7KL0066wjACG6eCidAxhoehB3Bamc7oYNCmLiufQrs4RPX5Lv rpH876jmYIgAj337pUHpla07+Y2hcrH8lkO+UEREZQsTDFT1E8bTtPK0wIK/aw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733460501; a=rsa-sha256; cv=none; b=rUKuZtcnKxkplU/ZrssxBo4L3vm5hetiPC1Rpe5Vn3oQVJc1fqIy8Fvl2N/hJjjNwVGj3F 5nMNs0EEERKCLjQ/FL+7bkZBkrz3z6N6X+pgd117xOv1+jiPquwJ+/HqmDgv4H4wrgmiSI 3zYlYtJjXTGxIKzjZG/dNW6/MMxygFyqOny9blXXyDsoXBrqlx0OFoCQ/C00qL3DZsRweC O3dQ0oFvXPWAqRtqbXzLBm6zfYHYMSDSv6BsY6bYsYq3WFts962+uQ2HxFktTy5imkuw+f igeF2uMrfE9miuhoHdlKT3tYqBzUxc4KvOaW3ouj8KlYM/qoog9MMzmerSLSUQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4Jfs5xs2zNVL for ; Fri, 6 Dec 2024 04:48:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B64mLKL098999 for ; Fri, 6 Dec 2024 04:48:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B64mLQH098998 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 04:48:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 04:48:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #5 from Mark Millard --- Why is LLVMgold.so not part of FreeBSD? The answer is, likely, licensing: QUOTE ( from https://llvm.org/docs/GoldPlugin.html ) Gold is licensed under the GPLv3. LLVMgold uses the interface file plugin-a= pi.h from gold which means that the resulting LLVMgold.so binary is also GPLv3. = This can still be used to link non-GPLv3 programs just as much as gold could wit= hout the plugin. END QUOTE --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 05:26:48 2024 X-Original-To: toolchain@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 4Y4KWD6C1fz5gLK0 for ; Fri, 06 Dec 2024 05:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4KWD3kBkz4M61 for ; Fri, 6 Dec 2024 05:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733462808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HItXLxcM7BJI+P3We8drM6sNKFxZ6vdvbeAer2mZDjY=; b=H7DzTv2+d0OgxfYXwvohL8GBjbjQI3DvP6Nb8jOQ0j1nvkl2HLf6sBMSuH0TyqIsZfmRR7 DeOLcAQ7xblnE9XDex/c32KYUcLQOoqrM6wLklz0sgCHDH3mEX4OnDsqc4yW85o1NpZWrq y1G4yNg4Xdgh9hYmWkWSPrsyAIZQiFQKVtEReOHmImWAnHVcFX3qccki+9hFnx/jq84owH 6gaz6+LwcC1l4Hzx3kCNMwYrBe0uSGbCh4wZ17m0aSwox0e43dbgckUhQxN7oAtyWS6psZ V3fiHbHDkrMHPiG5DOXNa3obt4NC9VNRAj8n/BjRkmR3E0zzcIz6XuGASwWCZA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733462808; a=rsa-sha256; cv=none; b=G2PRDjg+ib21bDMwxfPqFQPMHfmwDdb7KvsYclhLh4Dt6Y/JMvOl4nbnLgNdzmTRyNFqPK wkBkr0O1Avs3EukZJsxVAFaetelPAoLkIqs/8HHexmE1JKysPanwXtlhOd1l5BfdifDB14 MhtjN4byHY1YUIo8iORZNOujU6nZqWM6w8Q6BYbXn/VfKZiUiLHxFTFHAaMq3dALlRH/S+ nMmeoY9FXVPTOl/gWKIXDiUzTkKULyw9oPx3DdE8uVhrr9yhFEzSrI3M8rncaO/R6Itfvi vFzSAB6HAL5z4R3a3fMs1Z9XuwUgkQ+vXUtsF35WVmqaHBwQsCITfzj4H7Kq3A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4KWD3DCQzPKh for ; Fri, 6 Dec 2024 05:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B65QmSs061805 for ; Fri, 6 Dec 2024 05:26:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B65Qmtd061804 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 05:26:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 05:26:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #6 from Mark Millard --- Hmm. Having LLVMgold.so in the installed devel/llvm19 implies that the devel/llvm19 licensing should reference GPLv3 . But: # pkg info llvm19 llvm19-19.1.3 Name : llvm19 Version : 19.1.3 Installed on : Thu Nov 28 00:09:17 2024 PST Origin : devel/llvm19 Architecture : FreeBSD:15:amd64 Prefix : /usr/local Categories : lang devel Licenses : REGEX and PD and MIT and LLVM2 and LLVM and BSD3CLAUSE' . . . Also: /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFINE_amd64=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFINE_powerpc=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFINE_powerpc64=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFINE_powerpc64le=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFAULT_amd64+=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFAULT_powerpc+=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFAULT_powerpc64+=3D GOLD /usr/ports/devel/llvm19/Makefile:OPTIONS_DEFAULT_powerpc64le+=3D GOLD /usr/ports/devel/llvm19/Makefile:_ALL_OPTIONS=3D CLANG COMPILER_RT DOCS EX= TRAS FLANG GOLD LIT LLD LLDB MLIR \ --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 13:27:56 2024 X-Original-To: toolchain@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 4Y4XBQ1TR3z5gGkj for ; Fri, 06 Dec 2024 13:27:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4XBN4L35z44Fy for ; Fri, 6 Dec 2024 13:27:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733491676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RwuAf4XgbJzc4HGUwM1dP+/UdZbAVRif4QpNV6MKiWU=; b=bVGTw3hLAhSobJl51K+kKnYwmJlbi6LYjHJR3+mhB67ohqnDOJcIVeDqiLv3FWanTgLOEO +vbVMNK/s4zZmb8Veo2GJxkx3YJ7SAUKr5kC1QFVxGv5zq8Tac0dvNekBJpdBC6wAa1gQt 5JKBhtOpFc0Wj1Z0dikp7UmgbelGNm8G7kPE2RHh9bvRi4ISZaGykwn6yv2jNDB00Sx+uN hQSv/4Dg/anTr2oVjnw3BynktmcTTrM3z7FG55TVxF+hOEbUY9GJd8MOk8Cxy1Otom+Eb7 rpyMYbnkbQu0O7hbnghtITMRhPPOJ7EPbMkjIzy9Dhp9GdeuEFktxH+314pfGA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733491676; a=rsa-sha256; cv=none; b=jnCm3IzuFRJQvrxzkdyRlMjTcQUgokZYGjxzUnbWbBFUh1RnCoPG/r5X4xBWGhbBuPh/TK gRlrhDZt3Kx98b99Ql0JE79R1cHakoB+xKmTJ8W7lXmFNCmJwNiT1ZmvMfGPYy/BvhJFdI f6ofVLEssMsqGb3rJwEVO3vwMJ0inPlnKXvruSq5oeCtOaIA4YWvtW62gr+lUpzkRAOulW rLyYOxE7ctM9LT9pYii87IU3D5k6XQdM//wPHl14rvJD2oIGf77r79r6ZsFiP2Yo/fmWGi B5WTEBj73z9+dOrHFXmPLrMJq0jV2uVAYuvtsoEf1Fb1i1aPti6dxZJWk45Tlg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4XBN3qL8zfhZ for ; Fri, 6 Dec 2024 13:27:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6DRu6V046328 for ; Fri, 6 Dec 2024 13:27:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6DRuMp046327 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 13:27:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 13:27:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #7 from Dimitry Andric --- I don't see it here. With files/patch-Makefile deleted, a poudriere bulk bu= ild of multimedia/kew works just fine. Final link command line: cc -o kew src/obj/common_ui.o src/obj/sound.o src/obj/directorytree.o src/obj/soundcommon.o src/obj/m4a.o src/obj/search_ui.o src/obj/playlist_ui= .o src/obj/player.o src/obj/soundbuiltin.o src/obj/mpris.o src/obj/playerops.o src/obj/utils.o src/obj/file.o src/obj/imgfunc.o src/obj/cache.o src/obj/songloader.o src/obj/playlist.o src/obj/term.o src/obj/settings.o src/obj/visuals.o src/obj/kew.o src/obj/tagLibWrapper.o -L/usr/lib -lm -lopusfile -lglib-2.0 -lpthread -L/usr/local/lib -lgio-2.0 -lgobject-2.0 -lchafa -lfftw3f -lopus -lopusfile -logg -lvorbis -lvorbisfile -lglib-2.0 -lintl -ltag -lz -lstdc++ -lnotify -L/usr/local/lib -lfaad -logg -lz -flto I'm unsure why it would even attempt to use the gold plugin here? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 14:00:57 2024 X-Original-To: toolchain@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 4Y4XwT6kLYz5gKS4 for ; Fri, 06 Dec 2024 14:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4XwT55vfz49R7 for ; Fri, 6 Dec 2024 14:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733493657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vZgyu7Oq9UpfIUyeusPbFjOHweNa2kiwSjkgPm0kyw0=; b=bAWH+z2GHSWn+ZtuPT5+vXm9yCp8Ix9Kq4VYH4GXTgrT0q2sxtXQmZ2Ocuh5VlvfBX0xyD 8uAeLOz6BYBpRjpsaKxUwza5JiLiBlW+wT7zt0/0g2vJytdQwTIc/duwHqw4YuPMg8M8Ds iLGq8M9KEZpVxadVkl1YLpwbLBwsubwSae/irDiI0hfidQ1sq1Fd1ORWMeBt5QKZqF5E2K R3gMciJiF2M7Qfj5PLOSrE3ILT74fhyaB6kwPa/K7NToGfEdZlX5VcdT/RGwMFkM3hgJQo lZw/H4/EPdg5fAlpK+hri7PCiVzq9yS7VgC4GPAiZpV5kMA2mDKA0tUqF/Nulw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733493657; a=rsa-sha256; cv=none; b=LdnaVNVufHn18+CFBMIJbkL5MwJGeWpl6P1Nz43vNMBGra+eIXkoW5UypVYC/+E9xwx7UE WyUIrvT2BHiBFTn/wPcqUryfig4rYwRzXIxZav2A4lwZdI9O/5fW89I/yvo9BvhP6vGlfg SZz8LMJhyWotuUsCH8pND1qyqeTueMXYjy1hJx4kYSlROfJvC8/YPkVvQjxUsrFz35PBg6 L8jmzarw8/48CtGEpEbZugpLmRZlyoPoWru/hnBboExrScKty4NuzZc6Ke1uwPNKzvxKPf rdcCAxbVjPi4kTZTHgsYPl9znLbcNzFDNueB/3bmtegeM8XBsTZzyUAySBXcaw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4XwT4kPXzgv0 for ; Fri, 6 Dec 2024 14:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6E0vJi094968 for ; Fri, 6 Dec 2024 14:00:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6E0ve3094953 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 14:00:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 14:00:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #8 from Mark Millard --- (In reply to Dimitry Andric from comment #7) Probably how to reproduce the LLVMgold.so use attempt for direct make style builds: have devel/binutils@amd64 installed at the time so that the: /usr/local/bin/*-unknown-freebsd*-ld exists when the cc based link command is executed. Turns out that I've reported the issue to the lists in the past. An example is: https://lists.freebsd.org/archives/freebsd-toolchain/2022-September/000898.= html It even shows the example (aarch64 context, not amd64): /usr/local/bin/aarch64-unknown-freebsd14.0-ld: /usr/bin/../lib/LLVMgold.so: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" Sorry it took so long to remember. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 14:33:02 2024 X-Original-To: toolchain@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 4Y4YdX2DZQz5gMnf for ; Fri, 06 Dec 2024 14:33:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4YdV14bNz4DtP for ; Fri, 6 Dec 2024 14:33:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733495582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I6rWFfP+BhocS6f/7djFV+/JRWXZlyHzLcLgaGd/WZM=; b=f9zCuf695bv40vhU9BcFtfF0uIaVHqvyTrhqct5P4scRlnMylhpgSBN3f0mSqra5Xq9cbV IQ0TDfmSbzibhyHDN3oe9S1N/6x7GfoyFdjApH7WM3TVg5HKt/O3y5yqcivq8hYf4fmIBH GXAAku+y/682IxgL0O5NzYI7IwRw/MpLXD09edjHG7vK3AwZTNSQEXD4Jz4kkF0wt1C5zb J3ZClyqNI4E9buJVLutnRv0HH+tUZE9Br1R5W+3kgqCrYu3ntw6xJXnRRC5GIX3uDmFJ1g +xxfJmfRcCAlV20cO5wQ0NB8ascdctIWvLZdiWGoNvMOmDciYbEfCuX/zvriZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733495582; a=rsa-sha256; cv=none; b=Tyzqe4EuEP95S7Ttee+Hget3w8qvXuTwgBRAd367Mw/h+4OdxVXoRTaHODfVmJY6o1uON6 3R4UcB8Owuo2xAokDZ3wDusXxvOQMdyIKdzWS74W9eM2DI9W73Cux4ND6NjO0i0mkpvWxV dZF2gpzuLw4TUnbTx/sZCG4BspsIcC2Qw+4oYw/Qk7VQ+ydv4BYQ3j96agJvtePwT0X5LV uEYHl2C6c/VIZNLrO9Tbql9roVIiBtbba+0hshBJXkCufa0Mwn0cqqPbHnocn0B4IZkq/p k0hCuUdNs4IfBl/l+P0kK75EIxgbNdCHWrDLHZFj7TSTisf84bb+44SYxW8qMQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4YdV0NKMzhsQ for ; Fri, 6 Dec 2024 14:33:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6EX16G058389 for ; Fri, 6 Dec 2024 14:33:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6EX1K2058387 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 14:33:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 14:33:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #9 from Dimitry Andric --- (In reply to Mark Millard from comment #8) Yes, so the first problem is that other ports use the prefix ${arch}-portbld-freebsdX.Y-, while devel/binutils tries to be different, and uses ${arch}-unknown-freebsdX.Y-: $ ls -l /usr/local/bin/x8* -rwxr-xr-x 4 root wheel 1720112 2024-11-23 23:37:08 /usr/local/bin/x86_64-portbld-freebsd15.0-c++13* -rwxr-xr-x 4 root wheel 1720112 2024-11-23 23:37:08 /usr/local/bin/x86_64-portbld-freebsd15.0-g++13* -rwxr-xr-x 3 root wheel 1716464 2024-11-24 00:07:52 /usr/local/bin/x86_64-portbld-freebsd15.0-gcc-13.3.0* -rwxr-xr-x 2 root wheel 26208 2024-11-24 00:07:55 /usr/local/bin/x86_64-portbld-freebsd15.0-gcc-ar13* -rwxr-xr-x 2 root wheel 26144 2024-11-24 00:07:55 /usr/local/bin/x86_64-portbld-freebsd15.0-gcc-nm13* -rwxr-xr-x 2 root wheel 26144 2024-11-24 00:07:55 /usr/local/bin/x86_64-portbld-freebsd15.0-gcc-ranlib13* -rwxr-xr-x 3 root wheel 1716464 2024-11-24 00:07:52 /usr/local/bin/x86_64-portbld-freebsd15.0-gcc13* -rwxr-xr-x 2 root wheel 1719056 2024-11-23 23:37:14 /usr/local/bin/x86_64-portbld-freebsd15.0-gfortran13* -r-xr-xr-x 1 root wheel 1212928 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-addr2line* -r-xr-xr-x 2 root wheel 1245144 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-ar* -r-xr-xr-x 2 root wheel 1955200 2024-12-06 15:17:54 /usr/local/bin/x86_64-unknown-freebsd15.0-as* -r-xr-xr-x 1 root wheel 1211304 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-c++filt* -r-xr-xr-x 1 root wheel 38968 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-elfedit* -r-xr-xr-x 1 root wheel 1275096 2024-12-06 15:17:54 /usr/local/bin/x86_64-unknown-freebsd15.0-gprof* -r-xr-xr-x 4 root wheel 2236920 2024-12-06 15:17:54 /usr/local/bin/x86_64-unknown-freebsd15.0-ld* -r-xr-xr-x 4 root wheel 2236920 2024-12-06 15:17:54 /usr/local/bin/x86_64-unknown-freebsd15.0-ld.bfd* -r-xr-xr-x 2 root wheel 1229232 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-nm* -r-xr-xr-x 2 root wheel 1360832 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-objcopy* -r-xr-xr-x 2 root wheel 2533640 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-objdump* -r-xr-xr-x 2 root wheel 1245144 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-ranlib* -r-xr-xr-x 2 root wheel 1112456 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-readelf* -r-xr-xr-x 1 root wheel 1214704 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-size* -r-xr-xr-x 1 root wheel 1218776 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-strings* -r-xr-xr-x 2 root wheel 1360848 2024-12-06 15:17:53 /usr/local/bin/x86_64-unknown-freebsd15.0-strip* This particular bug would simply go away if devel/binutils used ${arch}-portbld-freebsdX.Y- too. The second problem is that the GNU ld driver searches in the wrong path for LLVMgold.so. If somebody would actually want to use LLVMgold.so (not really recommended), they'd have to first choose an LLVM version to use, then try = any of: /usr/local/llvm15/lib/LLVMgold.so /usr/local/llvm16/lib/LLVMgold.so /usr/local/llvm17/lib/LLVMgold.so /usr/local/llvm18/lib/LLVMgold.so /usr/local/llvm19/lib/LLVMgold.so That said, the better solution seems fixing binutils to me. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 16:21:38 2024 X-Original-To: toolchain@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 4Y4c2p44L4z5gW53 for ; Fri, 06 Dec 2024 16:21:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4c2p2hrJz4Qhv for ; Fri, 6 Dec 2024 16:21:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733502098; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bMrVsXfW1UNxsauhE8hVu6j93HfNDfL+2L3W44wobEI=; b=kM8tMCfSVJapHBitpnXlWQTFS+0ceA3BcwCsoO0vVuoUqgwgXOmXF2dE91Hd6lRac/Ury6 Am7tN2zV8j28SnEqW9vUV69NeHoaSrZyq9JOB0jPS8775PR4TxwJQJzRTG8HGJRT3HuAjI QqpohEqrYTubKZsiuELM15rwaZbH/Zq1AJHuUo9kjD4IEvgHTNALjjNiWT6dtGPMAsMYZb tVlQ2y7+6hRvfG4CD4i36OkEPGqZ/C1hiOWsxt4vmfjJPBZPTW4EQWxlICVqhqUDtklMKh 3N9Ss1VkcLFYJxhlmONzaGeNb+SdODJF61Qvkv/HkAjpd9xkuYmEI6ItT0lWoQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733502098; a=rsa-sha256; cv=none; b=Sjkealwz+5nKh78+5nsawmMG6nqDwXW4HDEhdRYC5GOQ+wkM0DeK+oTjJ2WdI3G5cM46rt jYq3yc3IpgIesAt+HNr6hkoJLHAewhtdn0mHQdrGRdxTsDLmwN63gZQfwMSXAtdSQJQ+B8 EyhYli+5FAVFOKqNHGwJ1cLXChSesf+bepJO4tXqKuVnbR8i8OfxmApd6epD67c6mDu7sp 2z2aBjNKehe9BPFmuKA+iODiOK3yExVcNoHjkZD/q8MdCOHejT9FT2YNxwn+7LRUmgv9W2 Z5byWKUW5Na8HBlgMRTgJoEPW50efo3JTlbZJi9lK5a+IKxpR4TEBinwiis7zQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4c2p2B7GzkM8 for ; Fri, 6 Dec 2024 16:21:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6GLch0033215 for ; Fri, 6 Dec 2024 16:21:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6GLclp033214 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 16:21:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 16:21:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #10 from Mark Millard --- (In reply to Dimitry Andric from comment #9) In order to avoid conflicts with lang/gcc* the following in devel/ use -unknown- instead of -portbld- as I remember : d--------- freebsd-gcc12 535 log plain d--------- freebsd-gcc13 535 log plain d--------- freebsd-gcc14 529 log plain I believe devel/binutils is set to match the devel/freebsd-gcc* . (Otherwise it would likely be lang/binutils ?) In the long term history, the change from -portbld- to -unknown- was on an earlier freebsd-gcc* that is no longer visible in devel/ --if I remember right. But it is possible that my memory is mixing in the old base/ history as well. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 17:43:10 2024 X-Original-To: toolchain@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 4Y4drv48yCz5gbXx for ; Fri, 06 Dec 2024 17:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4drt6GXxz4l2m for ; Fri, 6 Dec 2024 17:43:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733506990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2PLxStbd1zUEMqGZ9xYWM6m8JlkVxN9YdXqNV4bWJLU=; b=J+QiMFf83uzyfGl8lyRZx8lkANxCta+zZpT9bH1cVz9L+cIFVGSsgujRNt5ogvf4VhVKKv Hb9AS+9xjQpHz9o+K6S2Cs5orZ/8hfzACUN0toAHxjcRJ21XbzGKQ6Y1j3YOVJ9RTTG6g5 o9puMLGsX2VhaJqrzEa74FwBO3dsXDoqkKqHb/axvyCV1OVBh0VyzzRDAcExHkbulMvjKt QfjJ7l7Umg3zcBV4WjIU/NTZoUEzmwQrGjx0Y4HKY59K6are5TugWicOjx5t9XyM2nM+E+ 0oyWYEJ64udThTT1SYAMtq+vCfbUaz9xjxRpSq+0A70dIDA2mukb0pHlWLpArw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733506990; a=rsa-sha256; cv=none; b=atZf+p1xQ8OTPwpxSrVhgTwLTDZu4CtJ393p2fcT3MebZj1c6UjPu1hC1NLhucoFjYM0ek y8qDbZZvTxpIzr5Bvxt/ky9mVIx2TJaa1fFvdGIBzDDMJrV75rzjbm2+lPziglHyiLy13O PPSQlaE9huIkBZHDpG76W3wKonnPsZ0u91XfbkgIgrLaTSQKq3inZJj+9G85Yrl9p0DjgA KH8PY7L1Uamo2eejDf6KsS8xS1Pj+bjZsqW4IISIGmTaVDpgXqOlVl/FeCkwNZuokP2oIA 5BZSPzU8gl4guOA9z6cV0tqfS1T/JuT8JxoxRfk8oqEzuoTeKhUWPFrtOsrhdA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4drt5v3rznfp for ; Fri, 6 Dec 2024 17:43:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6HhAok067127 for ; Fri, 6 Dec 2024 17:43:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6HhAMO067126 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 17:43:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 17:43:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #11 from John Baldwin --- I would really like it if in-tree clang would just always use the in-tree linker and not try to find a "better" linker using the triple. I think tho= ugh you would still have the problem of clang from ports also happily using ld.= bfd from binutils instead of its associated ld.lld by default. Ideally the LLVM ports toolchains would prefer to use all their own bits as well unless told otherwise via -B, etc. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 18:26:52 2024 X-Original-To: toolchain@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 4Y4fqJ4stbz5gfgt for ; Fri, 06 Dec 2024 18:26:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4fqJ3K1lz4v42 for ; Fri, 6 Dec 2024 18:26:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733509612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YAB7OJezkTdM52a0zJrI74bXK0MfskEGP0etAKcNtqU=; b=CxiH7YVwLsotg5/dyYpaTQD90NSj6RhHtt2FCrZpgxDv+eKuZlFLPBkx14iToQid/LoG84 Ira6Cc2KFr/TfnaysOgQ8KbrrTbk5k95rfvo9LUSuYuM7IMIA0WRXMHSqPl30bJHX3IedE lncmyIDGwj7KAdDswjyLWi4FWJOdqHl4tPg1nnDRakIPGBdlWk87AHo5gVxQqkC+U5ixtQ dA1YHRhuAjm02hFSaW59UXFybMXpqD+rddfoBTdbKARwWbvoPMjXoZZ6eVcAepE8Tz+Gpj O/m/anjqL7aB0f/q01SIN7/jLKKisyZIai751ZxHAFUKVir0iXyD3bY7vVsolQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733509612; a=rsa-sha256; cv=none; b=L94woNMoXOEUDgpa2xscYsWX2huUBjbjNVUhR2zbSkbo2Y0MpXcl2xswWYMb2fzJEGBOew Rhw8aY8pNovIbIZfEXKj0lgXQwo404zoULkoJpMZq+6tQiAmX+miOb13Wt5BnSTwHqum8j dRQWAsRfP7HDlb1F18LEQhD4pP/Io2ahxUWdk5GY6/Qe+wSYSSQyeKmmRfwt32J55nUs0a 5oUPjee6E/RRZIOgWI1bQq3Nn2q+O5mJ+PgFaLK1sTcO6hvpSnwJeChnkWNBJJObqxIxyD SaNFD04UL4Ed6yZlT3aFSOWb/jib9dcK7OA0s0X25QSpGLqxEVb3J3sZea+57g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4fqJ2pgLzpKY for ; Fri, 6 Dec 2024 18:26:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6IQqTv044346 for ; Fri, 6 Dec 2024 18:26:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6IQqpi044345 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 18:26:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 18:26:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #12 from Mark Millard --- (In reply to John Baldwin from comment #11) One type of handling that avoids the likes of use of x86_64-unknown-freebsd14.1-ld is to use, say, -fuse-ld=3Dlld on the command line. (Avoids adjusting LLVM source.) But that is very specific to ld.lld and the clang code for finding tools is more general: const ToolChain::path_list &List =3D TC.getProgramPaths(); for (const auto &TargetSpecificExecutable : TargetSpecificExecutables) { // For each possible name of the tool look for it in // program paths first, then the path. // Higher priority names will be first, meaning that // a higher priority name in the path will be found // instead of a lower priority name in the program path. // E.g. -gcc on the path will be found instead // of gcc in the program path for (const auto &Path : List) { SmallString<128> P(Path); if (ScanDirForExecutable(P, TargetSpecificExecutable)) return std::string(P); } Does FreeBSD's built-in toolchain have any intended-to-be-supported potential use of -TOOL overriding TOOL from earlier in the path? Any deliberate use of such already? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 18:41:54 2024 X-Original-To: toolchain@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 4Y4g8f5wBvz5ggqw for ; Fri, 06 Dec 2024 18:41:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y4g8f3pb1z4xfB for ; Fri, 6 Dec 2024 18:41:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733510514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eRNvBI+Cs3qEHygEMlFtmKbkQfbuS1bSCUpK9egcdUo=; b=ttYwi4JQK6PuFXRoekbGQLDcAE8gIGdAdQilC6qFUCiDBiFanoex1ZcYsvkCCMQG2stBXk msp9bUzanPLgis/Yx0KY55u53f97snapgO/Iwf2aLOOzpkcd9Cr7+d3e1ZKN65e6eYHymc Sd76Ju5uIgwiBCUieR2/f45If+lDagq+8EA3+SgTHBAM/4NdLXTOV5bRc6dYEsE8MSmSIw u+UkFYbu3gT+eO+yA5kNAkSdcVytbYAcIsKl6nTjXZfTaY6sDuwlon8Ac49zM4oA6h3k6p mHusqN0QK7B2kupqzl2RrQgN+IHxxY/y5Yy6MZxQbXdus9TfHmpzPbCbpfG/bA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733510514; a=rsa-sha256; cv=none; b=BCHMXV/3v54PD1OXESE2LfkdnlRRcyMhAf+ewr+EtjPdvlMEix+LNikd8QAaacNGiypnwf roTgvBpC73fLdbdCAe0VLTVy8v1pjvu2vy6QAoX9TaNyMgftQgmsKEhV4pcXqHDUYUjnXf J4ezF6BBkGUszP4mFhFQEuK7mHvOyo7GyVyJfpQNxDr2ng2j8wPvne5c8QVmEyEndqLlPK Vntqo1GYKmHwQndRrJSdUuIWbPdJAKnOqQOG/y+t6zcs88yy6nzL6jXQGCmKOhN/JNsjOM 3NMvdt3uQ7m7RvmeOR3W6U5Y4mbrt4BEIOoNyYfzfUg1WsbTeURymyT79QFyyA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y4g8f3QTWzq8p for ; Fri, 6 Dec 2024 18:41:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B6Ifsl2071782 for ; Fri, 6 Dec 2024 18:41:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B6Ifsl0071781 for toolchain@FreeBSD.org; Fri, 6 Dec 2024 18:41:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 283155] Link fails with -flto: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" (port multimedia/kew) Date: Fri, 06 Dec 2024 18:41:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283155 --- Comment #13 from Mark Millard --- (In reply to Mark Millard from comment #12) I should have listed that TargetSpecificExecutables traces back to being filled in via: void Driver::generatePrefixedToolNames( StringRef Tool, const ToolChain &TC, SmallVectorImpl &Names) const { // FIXME: Needs a better variable than TargetTriple Names.emplace_back((TargetTriple + "-" + Tool).str()); Names.emplace_back(Tool); } So my final question traces back to if the FreeBSD system toolchain context has any need for the: Names.emplace_back((TargetTriple + "-" + Tool).str()) (The ports are a different matter, not being limited to the FreeBSD system toolchain's intended range of usage.) Even the FIXME note might be suggesting that TargetTriple content was not completely obvious as the best of choices for forming the special name. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Dec 7 19:11:28 2024 X-Original-To: toolchain@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 4Y5HmK5sG0z5g4Xq for ; Sat, 07 Dec 2024 19:11:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5HmK2dT1z49br for ; Sat, 7 Dec 2024 19:11:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733598689; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jlHkdfAOdD/OJhm+H3s36MzWLZbUOs6jJ9uqUHeSTMY=; b=ab1KjZWIA2fWqhXEiJPKTljaYUu5Ik2KIJLasB9/IFK2uLgMhyL+cu4J0QBY4hGpVlvAhy CIyxwu6vhDt4o7ejk9Z1qhTY0L+Le+dYXIjDxunIFmktHrFsWcfwpDTgCkT6oYfW0XA2jT Z8U512mv1kpsFd0tjC19Xv/HRisyJINs3gTBdfowTU/k81zTPau23z/NZQJFopBjYI2bqv PDSKjA3CWj7BlolttoSuZKL2fuKRbsjFst8R/H5yyDg/0A7lj7KDiWoKcQrw9+m05FwPuK KGlMdYe/+DyhFeBEkctykqR4iDG9oyIr+c9vJRryOQWA5ixFNf4AK6dbvP+Dww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733598689; a=rsa-sha256; cv=none; b=SNY+CJ/pQ2UkqJmB/rHVI80nrMJ4QD14937KEjyVvDvBXAmpHF5yckYurne0rda/azc90x rivxro/sIQDixevhIi2BBEIJ2ckqnux5LDscqqIsq3b/JP+yRl63ziAgPFC86MHizFNVyW evGByEeBqyh51b/NVg7zLu+h1ozW6rN5YqxjHIg9szaExITxA6U4sdnY3GxcIXOFft/RXn Y4GJS9vNfh+uxHthd26fkNDRlISBFWt7f9LkudMpWrPE1vgj7nrP5YyqlCxZVbyfQ3ZxHS Q5Nqr2IO22meRAb0+ZduRI9Zj73zR847xQwQ4e/ZKGa3qMssdIxfx7hDd3RfSw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y5HmK1tT6zKmx for ; Sat, 7 Dec 2024 19:11:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B7JBTdD094616 for ; Sat, 7 Dec 2024 19:11:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B7JBTHx094615 for toolchain@FreeBSD.org; Sat, 7 Dec 2024 19:11:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 249527] graphics/vulkan-loader: Clang 11 crashes on i386 during build: Assertion failed: (Type == RT32_32), function getRelocType32 Date: Sat, 07 Dec 2024 19:11:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249527 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |Overcome By Events See Also|https://bugs.llvm.org/show_ |https://github.com/llvm/llv |bug.cgi?id=3D47348 |m-project/issues/46692 --- Comment #11 from Jan Beich --- According to upstream bug this wasn't fixed but FreeBSD will likely drop i3= 86 before that. i386 is still critical for emulators/wine*/files/pkg32.sh on -CURRENT amd64 but vulkan-loader has a workaround, so no further action required on FreeBSD part. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Sat Dec 7 21:43:07 2024 X-Original-To: toolchain@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 4Y5M7H4GqRz5gFqP for ; Sat, 07 Dec 2024 21:43:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5M7H0vWkz4LZL for ; Sat, 7 Dec 2024 21:43:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733607787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lI2ww64NkmGiFEyz5FZJNtUWnDUU0PTAC+vYlHL5o/o=; b=X2MXdwbRHL1B6du0oFc6HIHrbxp/maQGOKgKPQV2SfSpRMHMNZzicWSwJMK2pljhp/92w1 IFwNNQP9fAlRwFQ8Qs+3k7bXhQEfdBKu8cOi7DWzgKvKxhn+hlYkFo98yo8BxIyUmjDmET 5ZZPPdajxRg1mqIG2xWNKJNlA7zm0XBujL2YP7DTwux3QkSY0o7jnhqm+XWCNPVgldEV5k vQ9t32r5h5YRiRYgaJBUsb6YwaBHg2fHYLRmsHg6BRMWvAJRICN8m7XZ98D8Vc5o+GxtpK jVsKmn6EZz2V9esjwA3WpgSEMHyx/OSn2Jg5hnLKcly6/DrJMcwwTt4u4LVRrA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733607787; a=rsa-sha256; cv=none; b=FHT0SWkIbB+1f+BhesN1LlfKg3zggfTlzf2rjoH3UGX3d41T7oSpb3JV5YMgAT+a8IMJ+p of5nzo3esBBrpA64v3uCxee0eFzx9M70tDHz+Cdpij6+6jxoCQ/twkwpSVRDp19jYeJ0ra xUFDxFjMDCrm3GbeK1DUfwVX/YNI9itw/RI/dYdXPd04mtiVbvbb6gnTrMy+9h9UMjBtcX PccuhX/WEDCKrEq149vlmONZbY7ZmlQc29if1jiSyds66H19vBvFhZw7n0yWuj1GZxALoh h9w68ZDW9iPxsZ7oO2OkI0My8xX2XIpq+kACVx4ymVNAmt3fl465sAco8CUQCA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y5M7H0WPhzPwj for ; Sat, 7 Dec 2024 21:43:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B7Lh6ih036074 for ; Sat, 7 Dec 2024 21:43:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B7Lh6Ua036073 for toolchain@FreeBSD.org; Sat, 7 Dec 2024 21:43:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 249527] graphics/vulkan-loader: Clang 11 crashes on i386 during build: Assertion failed: (Type == RT32_32), function getRelocType32 Date: Sat, 07 Dec 2024 21:43:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249527 --- Comment #12 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3D63a2582925484613f20f2420284ce44= 44c876718 commit 63a2582925484613f20f2420284ce4444c876718 Author: Jan Beich AuthorDate: 2024-12-07 19:31:14 +0000 Commit: Jan Beich CommitDate: 2024-12-07 21:42:04 +0000 graphics/vulkan-loader: drop i386 workaround No clue if or when it was fixed but not reproducible anymore. PR: 249527 graphics/vulkan-loader/Makefile | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Sun Dec 8 01:51:10 2024 X-Original-To: toolchain@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 4Y5SdV57p1z5fqHM for ; Sun, 08 Dec 2024 01:51:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5SdV2wgzz4jpH for ; Sun, 8 Dec 2024 01:51:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733622670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l+TXTJtTz+Ja4gi78BaHdHN2LEtDe3Vz/aRngLDaobM=; b=UZ2Q/Lbxa8StHt73p7wVyiDcNbQn/qU8KW4Uefz1GpAAJzan5ef8EmdA4s6NRtlLpxFmbe xC8bOgpWSdmRQ+374S+cPIH6tmgYY8YwuFCveVbeUryrxBKP4WIpzTL0pad02zCEYoQOzl xqln4hjMEeQ4z22r4macJPG6k8iC9CWH14qRW3KjBCpn/LPIkRjODWCdNuTi1xuNs8jD2+ aamwzoIl6hu0ijlSwHBuppe5mFUR/2Ld5qJMV069DccMOfEXpSrCK4iXx9Xh9u7f97j0iz NI7NM/UThI7PMPc++FwVmG3t6mTrDslO4S6vnmGi1sSprtjdEj2V8ZtgZ25R9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733622670; a=rsa-sha256; cv=none; b=B5th2g6RS+d4gMvv40h2S9oiuU/hKlE4uGjwQ0lYM9r61wAqGrgYOEOvHl6flFof8eJ8nm TSQoBNXooSRf9RFoiIk6BIfWLzBxq5gkrKzjy7mIOE/oaPz6bWTon7dZDvUYqxxgs6vh+c Z2id1y0qxLqK8o3v8s//9B6H2pgXYLMcqD//N3ucd+R250RLqfGUFxY9eft5n+0LBwriSH fBwdZKl4A3H6CloYxJS4qtx4lcbMQAaK+L5RzmKFEJqsWmguKKugSS9dz2yHlCmdmoUa2c 9ISlB4i1jrFVo+VPlt2qhldpgoRBrXTUiWyRr2/c9mWxpLt0AWpV3/uq+I3JIg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y5SdV2QjZzY3h for ; Sun, 8 Dec 2024 01:51:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B81pAOC044144 for ; Sun, 8 Dec 2024 01:51:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B81pA2L044143 for toolchain@FreeBSD.org; Sun, 8 Dec 2024 01:51:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 281765] llvm - ThinLTO never uses more than a single thread by default Date: Sun, 08 Dec 2024 01:51:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: diizzy@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281765 --- Comment #11 from Daniel Engberg --- Did we come to any conclusion about this issues/bug/"fix"? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Dec 8 04:02:19 2024 X-Original-To: toolchain@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 4Y5WXq5Tpwz5g0vv for ; Sun, 08 Dec 2024 04:02:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5WXq1QwYz4vrB for ; Sun, 8 Dec 2024 04:02:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733630539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WJvc4yy90Lqm/gZBHeUyZNsDEaRT+ArJdY3LsA/Zj5w=; b=Puy+WkZOX27b7JNl6ISoIoJaNE4/eLWwBAr5TK0MATvpJf7Q4RPLNX69rRz3ZZyNDcm2x+ RQIU5Skx/qRRTAgmWhSNk85Wq/3kfYpEn7z8WMKlCjiMXzEFZvQANFw3Uz4xbCEKaWLMG3 TmzvNCqFOtwtaZo8Zgv7BfIcAnVUT9ClvvTaI8VbqfZNMtnXJCPaejchm5GadMbFLjqiNT 82FZeOYr+ySGW7r8udsCX1eAy1fd4zBK+Q8qqZVHuJOtADEQwPEyLxu+B1FxnFIkWyUveL U76BCM2oaSvqgjz0ETguw862qI++vQfe3skWto4mQhAgflodEgp4lAjnNZOYkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733630539; a=rsa-sha256; cv=none; b=Wg0Ukpq9cK1gfhHR2W22inWEpn69FseB7BE2yqeY8qDuaW07S8ylg6n1tN5dutag7ypDc+ O0W5g8U6F0zjzuUwSXZv62FXFEvPe3doDeABbd0rQNv9DFlbzKyZKMGCfPtRsJy53c1V+n ZawWyrGaEVvDMfGrunhSCoP4EqkDyQvU0qxzzn3rvdpO7+ngQby7RMu/V2anUygJAzH9J0 TmggZlkGpKyGsUcy0CeBSA0kW/hKgxngOGnV6WwEMAgmJZ9JA9MDbr+KSUx2ZQDabOGwxN mMBZGeMrfPBwdTCcf4ur93py2rq7qRlvNXVpZBrjgcS+8d+sFliyJuCoKkwWsA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y5WXq13DvzcTV for ; Sun, 8 Dec 2024 04:02:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B842Jvt069596 for ; Sun, 8 Dec 2024 04:02:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B842Jxb069595 for toolchain@FreeBSD.org; Sun, 8 Dec 2024 04:02:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 281765] llvm - ThinLTO never uses more than a single thread by default Date: Sun, 08 Dec 2024 04:02:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281765 --- Comment #12 from Mark Millard --- (In reply to Daniel Engberg from comment #11) For devel/llvm-devel there was: QUOTE author Brooks Davis 2024-11-14 22:35:53 +0000 committer Brooks Davis 2024-11-14 22:35:53 +0000 commit daa99286ef8104d1df6c22e35d02b081cab2ed0f (patch) tree c0fb26926fe04858909faabb85fcf708882fc123 /devel/llvm-devel parent 6a2b178e527439794d5efba5bcf01561f4073121 (diff) download ports-daa99286ef8104d1df6c22e35d02b081cab2ed0f.tar.gz ports-daa99286ef8104d1df6c22e35d02b081cab2ed0f.zip devel/llvm-devel: new snapshot, 32-bit improvements Apply a patch based on one posted by Mark Millard in the comments of https://reviews.freebsd.org/D46239 which defaults lld to using a single thread on 32-bit systems. END QUOTE This does not address the parallelism issue for 64 bit(+) processes but keeps the 32-bit contexts from getting in the way of having such parallelism for 64+ bits, at least for devel/llvm-devel for now. I do not know if any other devel/llvm* will get such or if it might be upstreamed. With such in place to deal with avoiding process size limitation issues, RAM+SWAP can be part of what allows managing whatever parallelism rule is picked. (There will still be folks building on small aarch64 boards with only 4 cores.) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Dec 8 21:00:03 2024 X-Original-To: toolchain@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 4Y5y775sxjz5fBLh for ; Sun, 08 Dec 2024 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5y773J3Dz4TkH for ; Sun, 8 Dec 2024 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733691603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=noAw/GrE3CwpMz8Oavf0WiwgshM3eJKQ15ivLHTYV0k=; b=l66YswP27TZetK5XMM64B3M43tiTjWHN2xMZmc+WutqKoQ4/xA96hOU03NeqndbTLToiM6 NzTqgSHv3eCuL4+LY4oaEy1IumaHUe/puwZKTTUpnXp7f0CTw8egrIFm4RzAsWP5fEcSLz mHhE6Y5Dp+GjZLmBVLKvecdtPcmAwvELJvFgxBztfN43bnJGvLSyVI2wtpi2UIHxzqXSJd X0e3jDdhq8cyJjugbvBiR36EsWTOq25SIG9Bi5DxGmWo7Mcd+BJ3dIkcH4dhOO5DuerkhR LR1uWGKPTlbWgRGxxNfEVzIQV5UnmLtuXPfFUt1Bts75VB1kk3b4cCFqwaKvEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733691603; a=rsa-sha256; cv=none; b=Uubj26DMmfHB1AndlWYs8sRMdcUYZvuGEw5/p7OTWm/arVIJwwg8D/cqb9vzfEKrLJt+Pu RLSQ8w3Ee0FLvpV/9TJp1r9MBNoKDNeNnuPCl/efyBm6jpP1PVjKIukXqkZ5rlF9QIuBlG I4YFYpOF9250KL7uYKV1TnxnRxI+HMo0ur28eOsy35OVILNm64DBkn0J6raEE7l4PYo/3p ywvmMb2MNWGp1zvAI9pk6vGEhcl1Wr7tC37bI9aC/DD2I01CUk7UopeCP8yYCZwO/Y8pLP Cb2/XeRtwAbYgEyujLz1Xw37uiQarwvRO+sTQeTauyRmvt/7xdSnWLhg5ywKtg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y5y772n1bz17F7 for ; Sun, 8 Dec 2024 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B8L03jZ058000 for ; Sun, 8 Dec 2024 21:00:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B8L03OT057995 for toolchain@FreeBSD.org; Sun, 8 Dec 2024 21:00:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202412082100.4B8L03OT057995@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: toolchain@FreeBSD.org Subject: Problem reports for toolchain@FreeBSD.org that need special attention Date: Sun, 8 Dec 2024 21:00:03 +0000 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17336916031.e4E77.56865" Content-Transfer-Encoding: 7bit --17336916031.e4E77.56865 Date: Sun, 8 Dec 2024 21:00:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 271624 | emulators/qmc2: clang crashes during build on {12 Open | 192686 | Segfaults using combinations of -pie -pthread -lm 2 problems total for which you should take action. --17336916031.e4E77.56865 Date: Sun, 8 Dec 2024 21:00:03 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    271624 | emulators/qmc2: clang crashes during build on {12
Open        |    192686 | Segfaults using combinations of -pie -pthread -lm

2 problems total for which you should take action.
--17336916031.e4E77.56865--