From nobody Mon Jun 21 13:00:09 2021 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 1FD2511CC085 for ; Mon, 21 Jun 2021 13:00:09 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7qPj0KXqz3MHg for ; Mon, 21 Jun 2021 13:00:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 E7E221D82E for ; Mon, 21 Jun 2021 13:00:08 +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 15LD08fp017772 for ; Mon, 21 Jun 2021 13:00:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15LD08AM017770 for toolchain@FreeBSD.org; Mon, 21 Jun 2021 13:00:08 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Mon, 21 Jun 2021 13:00:09 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12? 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 --- Comment #6 from Dimitry Andric --- (In reply to Kubilay Kocak from comment #5) It'll abort on -CURRENT, where MK_LLVM_ASSERTIONS is on by default. On -STA= BLE branches, this is off by default. So unless somebody turns it on purposeful= ly, it shouldn't happen. That said, creduce is still going after ~30 hours of messing, reduced from = 41M (and ~600k lines) to 8.2M (~1600 lines). It's slow going, even with 12 simultaneous clang instances... --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jun 21 18:51:20 2021 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 EB6945D0E71 for ; Mon, 21 Jun 2021 18:51: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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7zBv6G0dz4chC for ; Mon, 21 Jun 2021 18:51:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 BE8B3221CC for ; Mon, 21 Jun 2021 18:51: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 15LIpJ6M002859 for ; Mon, 21 Jun 2021 18:51:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15LIpJOX002858 for toolchain@FreeBSD.org; Mon, 21 Jun 2021 18:51:19 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Mon, 21 Jun 2021 18:51:20 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12? 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 --- Comment #7 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3De7e517981a6591c79fb49cd8810361b0f= 3ad5983 commit e7e517981a6591c79fb49cd8810361b0f3ad5983 Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-21 18:48:37 +0000 Fix clang assertion while building recent www/chromium Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): [clang] Don't assert in EmitAggregateCopy on trivial_abi types Fixes PR42961. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D97872 PR: 256721, 255570 Reported by: jbeich MFC after: 3 days contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jun 21 18:54:09 2021 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 431E85D156E for ; Mon, 21 Jun 2021 18:54:09 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7zG91K8nz4cjv for ; Mon, 21 Jun 2021 18:54:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 159DA22733 for ; Mon, 21 Jun 2021 18:54:09 +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 15LIs9Oo004243 for ; Mon, 21 Jun 2021 18:54:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15LIs9Sa004242 for toolchain@FreeBSD.org; Mon, 21 Jun 2021 18:54:09 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Mon, 21 Jun 2021 18:54:09 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: bug_status 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress See Also| |https://bugs.llvm.org/show_ | |bug.cgi?id=3D42961 --- Comment #8 from Dimitry Andric --- In progress; will MFC this to stable/12 (and maybe stable/11) too, so people using MK_LLVM_ASSERTIONS=3Dyes there can still build Chromium. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jun 21 18:54:30 2021 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 E25165D1738 for ; Mon, 21 Jun 2021 18:54:30 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7zGZ60mXz4cmf for ; Mon, 21 Jun 2021 18:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 B6F6E221D5 for ; Mon, 21 Jun 2021 18:54:30 +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 15LIsUEk004325 for ; Mon, 21 Jun 2021 18:54:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15LIsUND004324 for toolchain@FreeBSD.org; Mon, 21 Jun 2021 18:54:30 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Mon, 21 Jun 2021 18:54:30 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13+ mfc-stable12+ mfc-stable11+ X-Bugzilla-Changed-Fields: flagtypes.name 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable13?, |mfc-stable13+, |mfc-stable12? |mfc-stable12+, | |mfc-stable11+ --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 23 08:34:55 2021 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 7B2BD11D15FB for ; Wed, 23 Jun 2021 08:35:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G8xQv1Nklz3pSv for ; Wed, 23 Jun 2021 08:35:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624437301; bh=jbX+M0Ok38rD4vh+GmgqTW4tSvL5hgPwZKg7Gg3G2Kg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hrr/PXKY1pSYIWr2eqNlzxCF3xvosIvtnO/Va9LRGMaV+vC6mlVUBts5rbxZZupFHwOeWrZwkM+u8V3jJVhhK2JTE1Fj1EVXKqtUhHQgjocLRcHBwb2iffv01n4x7fi4tC8HXsO7kg/2qkG3+Ys8b59+K1GpQhydtQiFOVnxa+STmFHpVNYk7hr3HIsVBWvdIRLdNLlOEd9W8dvIw63keyDi+vFTw37FiJk7vmKdKkdBH8UDrMI7w5MsMHFvBdUpytNeEKfsSdR1IfeFb6YQcB+nawdTk35OCvvRd4r9huMsVpBvAAB19Uinsi95rZ6NUxT0Sm+bYF2nBsrt3tOUsw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624437301; bh=FcH3JzEGKy4hDXFaf3M8ooEf9eGGWPQrgsCF73X7HT7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PFnANVCSdqKzk6UhIX5BkvER8JN1FLp2kcblw3ypcaOWDBHCpkp/JT1U3M+Kvz416IXT5NuO6bRqHXEZQowFQwYFTxeBQVLYm0Btcd278JZcWx4P2ELU4qtlbY7r2Zei3W66mPvjyAerxEC+m6H/qjHlwoJvw3DHdeyUujtJFDXbIqtI8I4+YMBHzAAcuk3S81b1PaBAsy62QsZQT1DED1Y9lAogbA0MnRLfAOyV5oR2LuAsBSYfpGrQnS/uTFBJ5VIKedRPrNnIoSWydsxWIpO9U5QWBr9hWRG82qDJTt2BC6uIkFHnVB+pdeSbA9Qe142OjQRKJBXW8U5B1O95YA== X-YMail-OSG: .E8AtssVM1lyhWYDg.U8H4a6W2wX2I2US5_tbvzSpp3BiQtwymPCVuyFj1H7NdM ESnzfxGetnTMICvxVNh4qjqN2M2vyfpNB4.PgkyaRe4Q91RnfBSWH.U12UE6WdJQE_pS28G97jOD 9.rORc26CtoZB2Q4pMMfZNsh5R._1wxqH2rJtBT.0DvHgy5iPjsVCqDEKOa.b8G.Gs3LA4An3qDF udlj7esc6uU2cChwmfbFV453Q3yRwDxS0.Uwf9BW7X8v9MuT6dQI5z532zef33CequyN99f.7TUP RLLY.oFAl93FCJhUpNsOJnmNh.ZfaC81qzOmG4XZRlip5fGovTNcMuzHCLzOPmlju8YIpDGVvSIa ARLgBWf29OHp5Y0My5FqiM5mE6l_cUWFJshwmm5HFq2_uU.OgmFrIMNnQTO6bHfiN0IGUywrlZRO RK5Cuvqy1USbla7drnAlOEIq3e5GjS4OEwgGnZe0XdszXSgAE98FJjCllagqjfZSrx_8Z69sx5Hy PK9y0CgM71uYsWJQ3R3ibzUSBnoO6CvNMkw8crvjUgj0kuMH3Vv6FE6nQ8JJECDoEHrVugzjV02E jXk6y2Dx_mo95ou74nA4iGqLsWklT77VE1Rncswgr5pjmETNs9kkeNhFiajv7vmQcfUUqPZi0SLH 1aUbjLJEWsolGbGGn.DtEXsYSNZZRKxSc2VC_5fMvqYSsf0QqKLlzmdW5eWZBLI5qYUkd3ugqbsJ zEnt_g48Pa7v3mPrN.i4oqgFLNlDljeFHPtK6YwKk4jkZmtTZf_KXNZsWvFIHIn7Nz56x4s0r4VU juwRugEpQtDaf1XG9wA4BFTXOXkUXyKh15AQ28GkThGG46nV8CVKQgnilLoYv_oPorMCZseOyjIn GCg5Mi2J0DgWHyWKW_bDMdNGk0Da_fcWdpk_.upYHFWoD9jbUrdlkONaQ6o7Pgg_RXdeF98HW6p1 iE21KukjX0b1hdMBTvhCyhiWjE.278vm59.L..iyH.3hXI68X1QHq7tBfgCuwD7FInKiu6IyK_Dx KYC_wXA2pJh5mG6f6cdKZvETGzlJ.HTNkkoDIWo2sva93ZiT.DFApSl5sC6aX7_GFM.19RZoZ8Da sQ1cJI2fdWPdk6.R5i1PuORig5CX1Nsmmxp4W47mbvWGiFiVVmB4RIRviznjy.JQOMz5eKTRscbD Py6IHHDKRxrUWBIobGrFeXghSttPsdeMl9PE6NdlEa5s80M45392GuqiqzMd81rwXv3YBBvNUUKe uhLbl8WJk.6oYWf65Lqb6tzEMBqwDo0xPCFsiM97e8G.n0rAUgOGw_LrxB6BtNpT0gnrvjueL03O MGMXMWxoj_3lTdWYn0jIrHirCuEwho16kKY4IbhrmLWYs0_xqg08a8WA8EKheq9aReY6OdNUM7XP ZWUzJu1KnfA6BH3vNtO5TZBCwL2z2CCBr6zxhCV1g5FKGTMxEBGFDOzl2KPQmzy7QzHNEHBubGGn kf7AdYwLNPzLeObHNsUA2hhvtqBC5dZCpGEsLC1hPKtJ2s2LOekzlXUr1vHsV6lFy_qN.5J74YAd Sk206F83zEO7hYbwMBwLm1EzcOGj0oELrZePM.aaYfBAqhy31mwGAA3COIktnDPjIQDaDeOdPa7M F_hm_urXwUpGsJLaoFJYMYKpXEOOAqVDF3FGA929pc_tOBIpPpjEQ2f6lQ3V9tXrzFsBWsGYV0R_ JvPRfrLvMmbFEYXtYfhCOXI7rBXCow_gHHrIw2491PwqyOZtK2NWiw7R1iEfjslS0usP8No8JNkM pTeRo960rG.dbf7wY9jsyuh1ave4mu1OsQQd7PmtAEgvaJpSGD_H0pSNN._huMb_iScyMUo6.C4i CS8GJi5qIuRTuW8PKMHaHXezbJ1qkPkBkwDdB.a0VVcIOiF231klwDS2zz8vMg_u7Z1fnhZBt78o 0s_eo9.aqbWbtxkXGeEe6Rf4rhv.0SlkjRRXjTfsh06Ui4HwNd4hQQwRsLXNBrbV.fjBxplkrjGa KiVWzNRnMRkcssL1sYZuzlZWJFuXloCpfCeIdF.IdjtoNZ2Zfo.6TRQ5iTeSkG6jq3wBcbq4_0wD F.PFhQIwvNOnKi1li.8.R9x8C2Vki_BgRbbl0QjY8emBESIDNGWUjrts8_BjLjkiBebx5bx.L2nG 2LId3pkJqEs_Jpvda6IkqE.j5jBKVH83haY0k6VhkDCW4aDX7jun462pLGnPkIzmSZAFwEUSs1Fd doUiv7iNcqhXaDMFfxmVy29Yc5Nr88VvbQwv.RO0F3whf_mw0g51C6wK.n8aA34BeNweRSYXwQCG X5AQXbJSYCERWCgVU9YG.cYxsOn4YWflYi0dpCTEb6994Q8t_zX0PmNB4ZD7PV.gHucu_tdPxLjR XnTZNCW.MkQD3_3Ol9tQRkNdlyFoJjGY9O.DnoIyyUEiwXn95SembpOhrc_GUnVhjjYyNxGqc6cr K42bOtM56RZSuv8oJUuEd5Z5GT7F4GRPo2KchN6q6q_Q8gErkP.PjSXYGad8ftH_6d5rK3Xo4Wqf HbWwbI9sudRNcAPA3hdNd6uMGFqJazC5fHlWEe67P7x3M7am2ckogllbJRJo5OXYcyhXLWv11cWq nqlQ7jon3MknpWgknKaJCs4bYeozwA1teqkOe2MSxCaUsy2vt4VlDx3.bx89dNxuERSAoQEL1noJ NTZBgRTkWMk8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Jun 2021 08:35:01 +0000 Received: by kubenode546.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 814e4ea526fa63b39abf154736296fb0; Wed, 23 Jun 2021 08:34:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210623050958.GA79888@www.zefox.net> Date: Wed, 23 Jun 2021 01:34:55 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210623050958.GA79888@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G8xQv1Nklz3pSv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-22, at 22:09, bob prohaska wrote: > Attempts to compile devel/llvm10 on a RPi3 under poudriere using > poudriere bulk -J 2 -j main devel/llvm10 > bulk.log & > are failing with: >=20 > In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUInstructionSelector.cpp:45: > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11138:50: error: expected = expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AMDGPU::SReg_64RegClassID: @2779096485*/, > ^ > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11138:118: error: expected = expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AMDGPU::SReg_64RegClassID: @2779096485*/, > = ^ > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11237:48: error: expected = expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, > ^ > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11237:116: error: expected = expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, > = ^ > 4 errors generated. >=20 > Not sure if this is an ARM problem, a poudriere problem or an llvm10 = problem. > It looks like an llvm10 problem to my eye. >=20 > The logfile is visible at > = http://www.zefox.org/~bob/poudriere/data/logs/bulk/latest-per-pkg/llvm10/1= 0.0.1_5/main-default.log > and the rest of the /usr/local/poudriere tree can be browsed as well. = The > config files have links at the top directory. >=20 > The ports tree has been updated between attempts, if I'm reading the > poudriere-ports man page correctly those updates should be in effect. > If I'm not a hint how to update would be much appreciated. Ports live > in /usr/ports, owned by root.=20 >=20 > The goal of the enterprise is to compile www/chromium, which has = worked > in the (distant) past using make.=20 >=20 Not that it helps much, but: 2779096485 =3D=3D 0xA5A5A5A5 It appears that such somehow was involved-in/generated by: [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d and that lead to the commented out notation in the output, with the = "@2779096485" listed in the comment as well. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Jun 23 21:03:42 2021 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 EFFBE11D7744 for ; Wed, 23 Jun 2021 21:03:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9G2v4PQkz3vB7 for ; Wed, 23 Jun 2021 21:03:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624482229; bh=NILNLtxClpNfwhrTl7+Xnux66VUE+BGumvU0XviLHGY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QfZiSnWt8YRFNbT9MEt+w+lCJJNd5iEAzINKFUv2mjLCZvhum/96SSs2WelzXg48Xr5URueFublqduWAu+00eYz4VIm27e3W9IQhIsyPLyvy79Ngm9whPVOda+RC0rCNO/zYWfYJEUxCWG1QG3TzrK7ZuPSUUccEaZU97N3qgvhWRDjsLJOK2ZP9o8UTVcBeqWcIZ9YoLEY3Yt4P08XId7IMexZwOVBy16/SCzpWWrUoMX/Nt3N2YiM/sZtQFI+9wvDL1ablLEE154ze10l6KgoOEjEymQ0Nq41uuFSQwsUetCx6o2y7fX78musg/aGT871MuOCtgrp+ls4ucosypw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624482229; bh=AM3bYhpNnjE4S3hvOWAbK2lC+n1VgM8JZphyn0V2wuf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=R3mT2mw/0Pi0/jA+lSR4GtsCWUPeak3enN4QUDDZbKZb/x3K0OqBcX1YaHV5uBFvKFUtabHuK4QbR9jz7gYeUu718gOjmb454RnN612bye8Z7dxmoqeCFVoDFmuypRAp33UswHtRUY6J05YiTP8EBVT2Dv63MnvCiWvvgq2ERvMEqw+i+0CMEj9VsM/EUFdR3nAPM5qN+lAWt86M5HqG8OxZ1hsJ1tQEaBjYmN78LBVn2NQL4ccYrvnFz9DjFk4u+Up38wp5BSlWYqck894Lqvc5dxs8DL3mtUiht1wG2OnAEEsJcSDQrYgrljLAuSmuHWSSMI6Ax3Qrpw4AkfKxxQ== X-YMail-OSG: cu9FBsoVM1lgNR_0pKtOpH5m8JbVIvH0Od18vSTJyiBlWUkJeydGe2Umv2Yv6JX k6QZlwjaMMqqp5r2IAnXqvYIjhQcFsZkLOX4KpZTvKunWbkCBhylV6.kXuryc3kE698ar1_JHVji IAs091s26yqb.J5FPpK1SkwZSMifrZEF27C6zxNyszNwBz0FqWoC_qUUM2pFopovWHvPaKWiym7n mNtoH.Fy7gDfWXD3IIdWvR07tTinZuTwBRoqdqCuElPEkuvZftfhRDU7yRCWUA2oGn3mW.Yw7MlY RhtVEzSIwEKjgCs9vp6w3N2LLfk6RmiD2CHSZeYj0.vIbkOuR.RXTNln835YbjMI3KZ5Tg7CJMrt u2CWmhtuVtsws_BZVdEneKx8gQw8MTUtI8J1HtSETgyKM_c9wqzKseEEgohnEIB0Q4urWho87NBd TbHXg_68VoxxWWyUeF3saR7QkXKBuAk8AL1w07f1WkYjKN3QFWuvPGAnbWxBTILUZDOQzsi1N8qp egj1nYxCoLbMtLC_4kbQaIJpj1q6WHYNGwmjZQ3UbUUvFS7flyDWG63u.xku8mHYSMsMG7k345RK HrceKfug6HvpySnMBk.cLzLhmOFvHgZT.cCmdGJ6iW1m6i3o1XechpTasdYiYNrAF43u2F1K43rM gAEUoX68XyAm31G9g637bnyiGSUJJwxY6IMIpd2UOTdr2GbbcjKL5Qd2jHRYba3J7xmMTaAt.gRu UtHdypDyD6T4S.gOabhEeX9mwDwSC2QpgSeVZMjA9fRa8XOVqqlW369DJ9YTRH24p.de4kKIjcLX Eh613nZodTDUsrI95_nxb.DAXZawOQbcHqCPozezavdm9Ip8AkOsttTqBSDlN53ppkRDEhGJddUu VwYp_MOHiNatJz3sbTNqD3MVMdYOb3CvRKDE58L.pQJR2DWNiJ9t4HKlCemgOFpWClZzoAN2dVZl hL4Ag5NbSDUBa2WbD.VfXbv0lItPtCun9SCqFpE3W.vWl1F21aOBfnoMoBifSYdzAsDu_4we8Jiv _bcgIdPCc952Ihuf0j6C89e2EHj7HuLOZtbTvJoPUBtDBVYX3vamD6Ed4S9OWp2S3_KH3NpnUtq4 mJcwKbCWSsdtnpV4kwfaKi0oFqB5Zz46cM7JS9v7Du0AbxUZGEL2E8v8f.OWNtGzdIPrqBjPHwTm cqz3OMxoJVPj_3E77qPIkFbfbVJQWg.3WOsEoy7HcZA2UqIUZxeb2dmlXMjXIQmSvuYzQfBwOMcQ sTaLQ0K3UqI0mpngvR326UHCftgDkRyvD_BxfN2zf42TvNvA65ty47ustkqyV4lqXvYRn3kcIxhB uH8ynQOtxGEM8BnAlvhwYF0w8W0SFqMA5Bi5L5LRii5Ld9qbFFF69L697U3mCl0oP6HUVybhDwCO hXGZFtq0V74_mau3plICzIvpFxMtaAnvTGFREWVdDT6XtJ9wsOwDqmQwwoh9z0sxXqWqVgIcfrC5 lsiL4dX2w40Uu0djpxRqb70DjLGN4.jQ8mmVQxIYY3Tp.DX7jcQBbyOqzSIPTjBIPQDYFsFjEt_d 1Oad759LhQ70zvfOWnsdH1qHIjIGY.GLJxTA8wsFrRsZvJHvVf8RGbl7xtTlsfxqf3l0zRJsJ31V PDtuy8.V2ysBOitFLtSQ_v9Vd_R.uOSsKzw00p8pv0yJmds9PjpvnhsBuL3MMjC4SBT.hMMWSkT8 mPZ_odcCvicN4VkGrllkBz6fuLsCNMlR9EMbXTewJX7ZrS8wFjC.L6xiemqJ8x3ZtcnB_3V4DQyn na_iFmCKCycFO_618R9tqhce59X8QRzA6V2S8PPBcS8QjG7ZRHaVhOgD7J31_1eLqcrREs9Wq4Mk hB8XOC2H4KloO8J3ZykHWaQbcV2qPTfrvJ.DXdUQ6fgpDmUXvPNkeDM_9vmXMvb.r2X2WZDuGHze nzahdZfGyJDRU9e5wQhmaaocjodHYQnxVMbvbJ_aGFRFneAvfvGMQmBxMOZjsrF0uU85A3yZPudY DrwF_.AdCU4nGKdKMqQm1YpQDJ5buecFmo2p4erjpvZXR2eUOTDgORBBn83zcnbyGltYq_uQlwHw h.kvB3RxfJMDY_wHI.FWHTJevJSO6O5ew.JqjcA9_BDMxG_WUE93pdoe49zYHh5ZyoSDnyt02RnT lLEiyDt.i.H2JXwmqewkeHHswcxDBHsa.35hMAh3_1ZALIu1R3k36seEfdN7ncIIW0g3okBZ_Z31 z_2OnuWLceeAMrPqiRUgHwEA6iyWKnKaNbISC51NgIQtqnkgt3CZPig6vt2jCPIORF7fNaFgMRlE 9KrAlNQXecOywI6Wr3vzZpPXIfv1ady6qzflXiZVoqK8osjIdhsnmrFIEh8eP1SzEv4ISav8ByiD csTRLFOmaz9NsEowiJ6QRq5l2VdrKfaIUBKM6h7hvq7DYaJDTcyTHjR3R05Bvt2S65CGAV5Qy9dC g2gd55_5aHZEfQvOMelEnQZ_Ns_W3fri22EHhCLk6t7WnoNvwpwMcCqXmU6wSAasmURJmT1AI85M jjhvz2VbX3Srkh9tH2xoykY.l6ibqZ5Bu2UGJjWvdBHNAPtyPz9nSWdf4VllbBPIE_AcDjwIOySN _fxMgRcg5MSnzF7FmG2kvi3xo6_DtWpCUSRS15uGfX1Ku7hTyhGKHWpqqcm9o2lawVYTeHV3NIXz 5JfjB4s04q_UUP5R2vXo7RVOVorp.Idm_cpbvDk0I8LUoLQJNbNdtieheXD72RYpY9I0p X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Jun 2021 21:03:49 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 319162b11ff0b3ea1d2c9ebd79a66386; Wed, 23 Jun 2021 21:03:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210623174338.GA84853@www.zefox.net> Date: Wed, 23 Jun 2021 14:03:42 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9G2v4PQkz3vB7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-23, at 10:43, bob prohaska wrote: > On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote: >>=20 >> Not that it helps much, but: 2779096485 =3D=3D 0xA5A5A5A5 >>=20 >> It appears that such somehow was involved-in/generated by: >>=20 >> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >>=20 >> and that lead to the commented out notation in the output, with the = "@2779096485" listed in the comment as well. >>=20 >=20 > A Pi4 doing a bulk build of chromium, lxqt and apache has gone far = past that > point building llvm10, suggesting the fault lies somewhere in my = setup. I'm not so sure of that for the 0xA5A5A5A5u value. You run main [so: 14 at this point]. Is it a debug build? Or a non-debug build? I expect that 0xA5A5A5A5u has some specific debug-build potential meaning. For example, 0xA5u byte values might be the value that newly allocated memory is initialized to. Looking . . . man jemalloc (the memory allocator implementation used by FreeBSD) reports: opt.junk (const char *) r- [--enable-fill] Junk filling. If set to =E2=80=9Calloc=E2=80=9D, each byte of = uninitialized allocated memory will be initialized to 0xa5. If set to = =E2=80=9Cfree=E2=80=9D, all deallocated memory will be initialized to 0x5a. If set to = =E2=80=9Ctrue=E2=80=9D, both allocated and deallocated memory will be initialized, = and if set to =E2=80=9Cfalse=E2=80=9D, junk filling be disabled = entirely. This is intended for debugging and will impact performance negatively. This = option is =E2=80=9Cfalse=E2=80=9D by default unless --enable-debug = is specified during configuration, in which case it is =E2=80=9Ctrue=E2=80=9D by = default. So, if you have junk filling enabled, I expect that you ran into a legitimate defect in the llvm-tblgen in use. Having Junk Filling disabled might be a workaround. There is /etc/malloc.conf as a way of controlling the behavior: ln -s 'junk:false' /usr/local/poudriere/poudriere-system/etc/malloc.conf I suggest you retry building after getting the above in place. If it does not get the 0xA5A5A5A5u value, that would be more evidence of a uninitialized-memory defect in the llvm-tblgen involved. I do not normally run debug builds and so would not have run into 0xA5A5A5A5u from Junk Filling of memory allocations. I'm not sure when I can setup and do a junk filling experiment (in a debug main build?). But it looks like some independent compare/contrast activity might be appropriate. > The instructions you gave for setting up poudriere seemed to work = perfectly > initially, but since that time both world and kernel have been updated > along with ports. Is it necessary or advisable to alter = /usr/local/poudriere, > either by update commands or complete replacement?=20 I will note that your log file reports: Host OSVERSION: 1400023 Jail OSVERSION: 1400019 So your jail's OSVERSION is older than the environment that it is running in. (Unlikely to contribute to the 0xA5A5A5A5u as far as I can tell.) In other words, you have not updated your: /usr/local/poudriere/poudriere-system/ to 1400023 as far as I can tell. Separately from that, for poudriere itself: I do not know if you are using ports-mgmt/poudriere-devel vs. ports-mgmt/poudriere . But, whichever, it is a port and is one of the ports that should be built when it has updated when you update /usr/ports content and should then have its install be updated via pkg like the other ports. I list ports-mgmt/poudriere-devel in the file with the other ports that I list in ~/origins/CA72-origins.txt and I use that file via -f in the bulk command. But nothing about these is likely to avoid the 0xA5A5A5A5u issue that you ran into. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Jun 23 22:28:38 2021 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 46BDF11DDB92; Wed, 23 Jun 2021 22:28:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9Hwj6ft1z4Xb1; Wed, 23 Jun 2021 22:28:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15NMScoQ085710 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Jun 2021 15:28:39 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15NMScgO085709; Wed, 23 Jun 2021 15:28:38 -0700 (PDT) (envelope-from fbsd) Date: Wed, 23 Jun 2021 15:28:38 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210623222838.GA85566@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> X-Rspamd-Queue-Id: 4G9Hwj6ft1z4Xb1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote: > On 2021-Jun-23, at 10:43, bob prohaska wrote: > > > On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote: > >> > >> Not that it helps much, but: 2779096485 == 0xA5A5A5A5 > >> > >> It appears that such somehow was involved-in/generated by: > >> > >> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d > >> > >> and that lead to the commented out notation in the output, with the "@2779096485" listed in the comment as well. > >> > > > > A Pi4 doing a bulk build of chromium, lxqt and apache has gone far past that > > point building llvm10, suggesting the fault lies somewhere in my setup. > > I'm not so sure of that for the 0xA5A5A5A5u value. You run > main [so: 14 at this point]. Is it a debug build? Or a > non-debug build? I expect that 0xA5A5A5A5u has some specific > debug-build potential meaning. > The kernel in use is FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n247405-8fa5c577de3: Fri Jun 18 17:03:19 PDT 2021 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 and it can invoke the debugger using [enter]-tilda-control-b. > For example, 0xA5u byte values might be the value that newly > allocated memory is initialized to. Looking . . . man jemalloc > (the memory allocator implementation used by FreeBSD) reports: > > opt.junk (const char *) r- [--enable-fill] > Junk filling. If set to ???alloc???, each byte of uninitialized > allocated memory will be initialized to 0xa5. If set to ???free???, all > deallocated memory will be initialized to 0x5a. If set to ???true???, > both allocated and deallocated memory will be initialized, and if > set to ???false???, junk filling be disabled entirely. This is intended > for debugging and will impact performance negatively. This option > is ???false??? by default unless --enable-debug is specified during > configuration, in which case it is ???true??? by default. > > So, if you have junk filling enabled, I expect that you ran > into a legitimate defect in the llvm-tblgen in use. Having > Junk Filling disabled might be a workaround. > > There is /etc/malloc.conf as a way of controlling the behavior: > > ln -s 'junk:false' /usr/local/poudriere/poudriere-system/etc/malloc.conf > > I suggest you retry building after getting the above in place. > If it does not get the 0xA5A5A5A5u value, that would be > more evidence of a uninitialized-memory defect in the llvm-tblgen > involved. > Done and running now. In the interim I tried building llvm10 using make in /usr/ports, but it failed with another python conflict. > I do not normally run debug builds and so would not have > run into 0xA5A5A5A5u from Junk Filling of memory allocations. > > I'm not sure when I can setup and do a junk filling experiment > (in a debug main build?). But it looks like some independent > compare/contrast activity might be appropriate. > > > The instructions you gave for setting up poudriere seemed to work perfectly > > initially, but since that time both world and kernel have been updated > > along with ports. Is it necessary or advisable to alter /usr/local/poudriere, > > either by update commands or complete replacement? > > I will note that your log file reports: > > Host OSVERSION: 1400023 > Jail OSVERSION: 1400019 > > So your jail's OSVERSION is older than the environment > that it is running in. (Unlikely to contribute to the > 0xA5A5A5A5u as far as I can tell.) In other words, you > have not updated your: > > /usr/local/poudriere/poudriere-system/ > > to 1400023 as far as I can tell. > After one of the world/kernel rebuilds I attempted to repeat your poudriere setup instructions, thinking it would update the setup. IIRC both commands were refused, not with an error, but more like a "don't do that" sort of message. I fumbled for a while with poudriere ports -u, but couldn't get the syntax right. Then I noticed a reference to null-mounting /usr/ports, which strongly suggested any updates to ports would be picked up by default. > Separately from that, for poudriere itself: > > I do not know if you are using ports-mgmt/poudriere-devel vs. > ports-mgmt/poudriere . Poudriere version reports 3.3.6. I believe it's _not_ the -devel version. > But, whichever, it is a port and is > one of the ports that should be built when it has updated > when you update /usr/ports content and should then have its > install be updated via pkg like the other ports. > I've yet to master getting pkg to actually work from a local repository. The handbook says to create /usr/local/poudriere % more /usr/local/etc/pkg/repos/FreeBSD.conf containing FreeBSD: { enabled: no } Hopefully, using pkg install -r /usr/local/poudriere/data/packages/main-default/All [pkgname] will do the trick. Any cautionary tales would be much appreciated. > I list ports-mgmt/poudriere-devel in the file with the other > ports that I list in ~/origins/CA72-origins.txt and I use > that file via -f in the bulk command. > If there's a guide to using poudriere/pkg in a self-hosting situation it would be very useful. The existing docs have a very different focus. Thanks again for reading and replying! bob prohaska From nobody Wed Jun 23 23:22:35 2021 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 C58155D0A7E for ; Wed, 23 Jun 2021 23:22:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9K772sHpz4ccB for ; Wed, 23 Jun 2021 23:22:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624490561; bh=EgPVagRXb9V2mkrcE1TOCWW5Qx3LDHWqsK31s87+eEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ePXEA0OekYD6BtL8nVFmzIZUtSvMhiiu78qSPr5tIRrhU9qqkXxmqvQ5YoBaPA2Ef829WIaJKXJvfsvGdpTaenoc3bABcY6OdIi4/McoxBhFhY7yotmK2u4X7594TJCY4SawUa6Ck2wjvHQGkdZOXhkOE5jQ1BpktW2N+yms4bY5g1xNHwmgOmNxDCVsjfp0+yRhTVEmcrKPFJORFBwtitx/tG1J7wqc7c2inZhfXXnE5ELY08duq+oy6LH/mA43jZFuVLqQL2soWcx42S7clYjBjUAjYp42z8rAP3LXipUBfAJDCL80jtlt+ZMUVX+JXxVPTLyPAl7LqVLygdGPrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624490561; bh=gi2Tzl2StBpWdVxziw/BD4I5u43uAcVNTxzRIT9Gfk+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=B/Pvar4BioYiRFec+JTcqwmHBQ/ztN6xOYStwXFPKPgICp9zrM7z+t/FjdtBZibco0zWh/0btjlWnxTLp5IMzj+z/7bhR/l/lLntu8/c+4VI2ORpCKemsP583tu2zjxq8vxMzoCXgop7iycC0JXC42Bo6SlYOyCIViWBH1/iUfX4pG29j5ViqFE/SphtOPEf5j0TCrYPHG5BCCMvOdKq5Ho0bTPdZ9wEYqErqGPP+TLMjV4Bqe2R7SUuZwgswDZewUc6ePLfTfaJ6zKdSVC2OyhB4C4Nt/fwFGLARZhh7kyVxmf5EEwUbr4clZd3LuR2bbJeCeKAkZZ8Rtu53pQKQw== X-YMail-OSG: e2fobP0VM1mfQkByvmlxNjFk9ACQV1hnI6gIa4nxAPtZbmp.V4W.ralhK2QBeyJ 1j.OAiELYcN8Kyu_DKmfjWjl5lUQezeZCmRZH4Edib1WEPPZh2K9Q8uf97UcZjEW6AH0TDDP2pS0 8I4M3jOXi.ajadhc3WihvWeyt6kiIlygMiWaMWbAQ9mxVotOZTill8dV5SkA7oVOyNtd_IR0Gpig .Vvj6OQQyxaKWedTMgS69299.ZtmkxnZACK9i595IN3ZLvqYDoyGkxUloQwJdknu.ytnPAXkn.SE f2k8VJXB5Yf6.uAABBDErU.3GeZY3DjjOvjgoSRbdkQgwsuSfiznI6IfFi6vKLo2cS516FHVOPoM 51gOaZ0HoKuA66Ol_NEYfhgcT1.IT7ytYkyFlmz9J.YWI.tCq0Y7Xpz1a5pyMBsu9XerxemT.Osm 8SNFduGmTuXZv8AGNOkiM5nEHja6KZ_X3O_Lf.7cw9R3lf8dQ09TvYMkGxtQwZUJCQXUWLlk52It _U9a2VG5vble.Ty5PedVP_hLM4R.JECxwnF1Z9ts2CGTGInfDlcw.wbPP21u0NxINCiYGnTwYH3_ 9W.zOxueFo0ue4azsmc6MeOfEeo5BcNMPGLrRgWbzj1JJAMvrofXmLD4tATVDfRphtMrgV2.BAVh IZYd81nY1avxY1lXmWtpSCKVqCeototgZppTpFN0K0EdIq67lzHuqb.mMSQC5tjr0GnwQeH_AwYM jP3nHVSYv1FcjnCrx5br8beth_f.sBDByTRqKMitSfYlfns.VrjcrgWGnYo3VlSsGmW2mpsMqhpe VwvaZoT2JuOTs7gVw7YB53ojtZPDteqmfxXcA.bliQ9juiah_AByHjsDyJw94gNPmQASaMmbJcBN pv7XVWkPYYaZ4T8TRuOL_Rnq3CZPalgAN9_Q1hIbRPNLoYMFos49BiH71gAd6OgSB6frxktIH9sn NlZwQLYO6bU6E9nFgO_yWjocl5RZY9.cg3ct6xbHrMk9bS7wSVc5ZZurT9PLk.zKoa1nlg6dk3Hy pDenyXNhUmeoetoQfbBwe5FQeaz..ig4zKRhX.4WiFKZ0N5rJWcbg3oDZGWC2NyuzdFkDQVNu2OS Fri4v9rIjXaGzANN0az8I92D3LS695MLm1JDN6lmernoh6suVTZNVsaPq5H4GjGJYv6atBIX7sfy xk7ZdA.wZdKDwZe713ZqnLBhOeXDofCuAPcA7Iy93rWsOEioNIh2TrBOlJjaT6uZoLUhAEmPwSjI LdmsegNU2KB5wgrg1oorgPWbc6ixBsF9dcfAqFl7oeNhFCD7AgC3E_AUtsaHaTaP3fdN5TjFqxol tPeSFe._7D58oAUrjEsjl42IBo9JbIFGBW2SRu7KsUOta9LTnvpT_nJTvXIOA4lOCu0EWPhQZ8Q6 5LWGgJQEkM25UKNV15_FdOHZC0dKfdSljIu3vKGUHr71BU5VlCsh5xWQRNP0.XXgq6gCaEz97Jq_ AR2TQIIpjh9e1oBE0vL_GI3tAwau__fWG.jm4k34nYzeSFVBnFqgM5U1enLZZkQP.leQjfdSQACm BlPoJVr7beo5fJHi6PQJITGDLlJr6Ep2ilwMAsw1aCeE0s72ztZhengZIEi9ayE5ZHSPunGW9A33 LQjRIeJ0Mv5ZJaenD9hS0vfyOjUviygYa0YI7daYFamI1.uOhW8s65amy2pr0DTIYWx7FF6W6lG1 HFFvC1JDSZFgXzKXDEH7jsWBUxhhq8qXkDQFeas5BX3wfeMRKc2sGkENSs3wWWb5Be8K05FMToUY gwoAHbrR5mgK1wIF3pC9wEC7HRtiSqKofsQTIbtQvXZwzn1JxPTziDAbZJMpYrkJLb9_ZnIZ7SRH WUGZ1ueOHC4plRybCQKSHVzEejiaZY3wg4xFl5BJAr6.xZfZcetXePCr5ODs65.CHK2rmR9qKtO0 LQ3arSg2GHZLlXjXoCiK.0ethw4pw.ds.dFx6ZinLz4288tpGVgY0Y_9rqgcUy9s63Fjd1jTMBI4 3wJMSTo8OamQdcZlttj.bjwxnN5vKtSMntzPecZ5Z9IGbkF8RDuHS3X.yOniUt5MjizKKRjZHJFP zaG1HZDy4f_.idtX4wBlX1QZN.cg06hFlMisUosNJUWGSrnKwyBF2Uu4n_SgDQ0GDQTWcjKPC8vh RIH4UyyWjsFvdvYzVaCUqATUNmP0Kk5Mej.V51wEzKeoHbPVBY839k3j50ErJ4clRwdyPlD8T02l Z61nl5VyPvpsX0MVQRRFQaZnS_ur_67Gz9RMPh188NL6qXEUx1Gs6BKrdnoTIZaPC3X7K.E.hQln Yj4qrj0dtfSV6yeeJhsxdEv4QjyZBQt5uXyyZ2zQvoPd.GGHLKgig96uwIIouUohpH7ubCUxO.Pb caDb.mu5n.aIWl2dyDvAOQ6jXQ7z.hjY9q9fyRfz2j05ycKprXTQ0NJNHkqkQd7jA40iQAJR82PE vc6QvU4K2TxY.fnKE.wo8zm5T4P5a6ewHMemtMRjVm9a73CnaQPyYLzeK31RSuk3yaITdo9_qgMK AOkSrPaBNi.5v.b6iqwtEWR4Eq2.qUCkH57fkzUxO6JWrwynEQeyxc..9hk4cMqWA888p44ZvDyX sYQkPrXULOFEJwoZtSeJgaegQxKlyO3YR66DBNtMwe8avkxRpGCAD96Wvw0XpnqIsHn8Emr8iE6v B9RHxKlDuQgKrus6xhRltlbPvL8DsxFSWvjbDSr_4FxgIsvfV6WaYQnwYCwGi_SIPXyUovg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Jun 2021 23:22:41 +0000 Received: by kubenode541.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8134c30be8b3f4dfd81031bfe68c4232; Wed, 23 Jun 2021 23:22:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210623222838.GA85566@www.zefox.net> Date: Wed, 23 Jun 2021 16:22:35 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9K772sHpz4ccB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-23, at 15:28, bob prohaska wrote: > On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote: >> On 2021-Jun-23, at 10:43, bob prohaska wrote: >>=20 >>> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote: >>>>=20 >>>> Not that it helps much, but: 2779096485 =3D=3D 0xA5A5A5A5 >>>>=20 >>>> It appears that such somehow was involved-in/generated by: >>>>=20 >>>> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >>>>=20 >>>> and that lead to the commented out notation in the output, with the = "@2779096485" listed in the comment as well. >>>>=20 >>>=20 >>> A Pi4 doing a bulk build of chromium, lxqt and apache has gone far = past that >>> point building llvm10, suggesting the fault lies somewhere in my = setup. >>=20 >> I'm not so sure of that for the 0xA5A5A5A5u value. You run >> main [so: 14 at this point]. Is it a debug build? Or a >> non-debug build? I expect that 0xA5A5A5A5u has some specific >> debug-build potential meaning. >>=20 > The kernel in use is=20 > FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n247405-8fa5c577de3: Fri Jun 18 17:03:19 PDT 2021 = bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM = arm64 > and it can invoke the debugger using [enter]-tilda-control-b. If it was a normal style build of main-n247405-8fa5c577de3 then both the kernel and world would be debug builds. But it is possible to explicitly control if MALLOC_PRODUCTION is used instead and the like, based on how doing the build was configured. (Lots more can be controlled for the builds.) I still can not tell if it was a debug (normal) main build or not. I would guess it was a normal debug build, no extra disabling or enabling of such. Side Note: Going in a separate direction: do you also run main on faster aarch64 systems (RPi4B's)? Do you also build there? If so, it is possible to make a copy of the poudriere/data/packages/main-default/ tree from the fast system on the slower system and then use pkg on the slower system without doing builds there. It is also possible to set up to have the fast system be used as a remote source of the packages, much like FreeBSD servers. But I've never done such. Based on what you have done to publish for folks to look at when they are helping, you might (mostly?) already have that set up, other than pointing package to the right URL on the slower machine. End Side Note. >> For example, 0xA5u byte values might be the value that newly >> allocated memory is initialized to. Looking . . . man jemalloc >> (the memory allocator implementation used by FreeBSD) reports: >>=20 >> opt.junk (const char *) r- [--enable-fill] >> Junk filling. If set to ???alloc???, each byte of = uninitialized >> allocated memory will be initialized to 0xa5. If set to = ???free???, all >> deallocated memory will be initialized to 0x5a. If set to = ???true???, >> both allocated and deallocated memory will be initialized, = and if >> set to ???false???, junk filling be disabled entirely. This = is intended >> for debugging and will impact performance negatively. This = option >> is ???false??? by default unless --enable-debug is = specified during >> configuration, in which case it is ???true??? by default. >>=20 >> So, if you have junk filling enabled, I expect that you ran >> into a legitimate defect in the llvm-tblgen in use. Having >> Junk Filling disabled might be a workaround. >>=20 >> There is /etc/malloc.conf as a way of controlling the behavior: >>=20 >> ln -s 'junk:false' = /usr/local/poudriere/poudriere-system/etc/malloc.conf >>=20 >> I suggest you retry building after getting the above in place. >> If it does not get the 0xA5A5A5A5u value, that would be >> more evidence of a uninitialized-memory defect in the llvm-tblgen >> involved. >>=20 > Done and running now. In the interim I tried building llvm10 using > make in /usr/ports, but it failed with another python conflict. Intersting. I'm unable to see a: /usr/local/poudriere/poudriere-system/etc/malloc.conf via what you have published. But I've no clue if such an odd symbolic link would be expected to show up. >> I do not normally run debug builds and so would not have >> run into 0xA5A5A5A5u from Junk Filling of memory allocations. >>=20 >> I'm not sure when I can setup and do a junk filling experiment >> (in a debug main build?). But it looks like some independent >> compare/contrast activity might be appropriate. >>=20 >>> The instructions you gave for setting up poudriere seemed to work = perfectly >>> initially, but since that time both world and kernel have been = updated >>> along with ports. Is it necessary or advisable to alter = /usr/local/poudriere, >>> either by update commands or complete replacement?=20 >>=20 >> I will note that your log file reports: >>=20 >> Host OSVERSION: 1400023 >> Jail OSVERSION: 1400019 >>=20 >> So your jail's OSVERSION is older than the environment >> that it is running in. (Unlikely to contribute to the >> 0xA5A5A5A5u as far as I can tell.) In other words, you >> have not updated your: >>=20 >> /usr/local/poudriere/poudriere-system/ >>=20 >> to 1400023 as far as I can tell. >>=20 >=20 > After one of the world/kernel rebuilds I attempted to repeat your > poudriere setup instructions, thinking it would update the setup. > IIRC both commands were refused, not with an error, but more like > a "don't do that" sort of message. I fumbled for a while with > poudriere ports -u, but couldn't get the syntax right. Then I > noticed a reference to null-mounting /usr/ports, which strongly > suggested any updates to ports would be picked up by default.=20 The steps in question for my point are (from your http://www.zefox.org/~bob/readme ): # cd /usr/src # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 Your: cd /usr/local/poudriere # poudriere ports -c -m null -M /usr/ports # poudriere jail -c -j main -m null -M = /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT leaves /usr/ports/ and /usr/src/ automatically bound to the most recent content from the system. But the installworld related material is not automatic. (And poudriere should not point at the live system's own materials for such: during operation it temporarily changes some things in the system it is pointed at.) >> Separately from that, for poudriere itself: >>=20 >=20 >> I do not know if you are using ports-mgmt/poudriere-devel vs. >> ports-mgmt/poudriere .=20 >=20 > Poudriere version reports 3.3.6. I believe it's _not_ the -devel = version. Okay. I've always used poudriere-devel . No reason that you should but now I know that we can have some distinctions for poudriere itself for recent functionality. >> But, whichever, it is a port and is >> one of the ports that should be built when it has updated >> when you update /usr/ports content and should then have its >> install be updated via pkg like the other ports. >>=20 >=20 > I've yet to master getting pkg to actually work from a local = repository. > The handbook says to create=20 > /usr/local/poudriere % more /usr/local/etc/pkg/repos/FreeBSD.conf > containing > FreeBSD: { > enabled: no > } That is part of it. I have: # find /usr/local/etc/pkg/repos/ -print /usr/local/etc/pkg/repos/ /usr/local/etc/pkg/repos/FreeBSD.conf /usr/local/etc/pkg/repos/custom.conf # more /usr/local/etc/pkg/repos/custom.conf=20 custom: { url: = "file:///usr/local/poudriere/data/packages/13_0R-CA72-default", enabled: yes, } The file:// prefix is URL notation and the rest is the directory path, including its leading / . So, for your context: custom: { url: "file:///usr/local/poudriere/data/packages/main-default", enabled: yes, } I'll note that the default for remote use of the FreeBSD servers looks like: # more /etc/pkg/FreeBSD.conf=20 # $FreeBSD$ # # To disable this repository, instead of modifying or removing this = file, # create a /usr/local/etc/pkg/repos/FreeBSD.conf file: # # mkdir -p /usr/local/etc/pkg/repos # echo "FreeBSD: { enabled: no }" > = /usr/local/etc/pkg/repos/FreeBSD.conf # FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } So something somewhat similar likely could be used in /usr/local/etc/pkg/repos/custom.conf to use a faster machine's packages via a slower machine's pkg, without coying over the directory tree that contains the respository. > Hopefully, using=20 > pkg install -r /usr/local/poudriere/data/packages/main-default/All = [pkgname] > will do the trick. Any cautionary tales would be much appreciated.=20 With an appropriate /usr/local/etc/pkg/repos/custom.conf you should be able to use pkg normally. The pkg install -r installs more than needed and not in a way that pkg autoremove would clean up. When you get pkg working with /usr/local/poudriere/data/packages/main-default/ material, you might want to do a round of deleting the installs and then only explicitly installing the things that you directly want to use. The rest needed at run-time should automatically install, but in a way that would allow for a later autoremove to work for things that are no longer being used after an update. >> I list ports-mgmt/poudriere-devel in the file with the other >> ports that I list in ~/origins/CA72-origins.txt and I use >> that file via -f in the bulk command. >>=20 >=20 > If there's a guide to using poudriere/pkg in a self-hosting situation > it would be very useful. The existing docs have a very different = focus. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jun 24 00:58:56 2021 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 0AB6D5D6038 for ; Thu, 24 Jun 2021 00:59:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9MGH40rpz4jqV for ; Thu, 24 Jun 2021 00:59:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624496341; bh=mBShoWOxpueXdIDIjNrLUGo1y2DM6nNl2UtZrdqPUNk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UIC5B/ty72EAApNt71RfjvL/LEMOEc4AiDCyNSKghhAuhBCboqFJn0kO6VLRvmbrKBcZkPvUSIjaQBB4/YdPc+2NLFM1avDlO3RZjdeLb2k8n3Omhg1eTxrBS7iBeHeZvVmXFua2PS4zSO60Vr2D0GNIK/Vn8DwKe1yuz+J+0oth+haWsOEkfiYRrLRUsxz3UuWKDIyY53Z6yqr/20S9WjW6Tx2MmALVYmVJRhAC4lyjmdsWqtYHo4jE2sArNoncicDwx5AkzpPo9fPtzkZu4sRsiJYJ36yMXgaIIF64sq6aiS2dVFXKj7frjDffJLlYj8AWA7xhuD8qBYlYj4ld4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624496341; bh=qIYrBfCQaqPucRZsy3HyYYOD3mRz3I40APMRPWcGmUv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iVXYTYLa7E5G3Ozzo/Y4si2asZDSnNTUU05thYXSUPkOGFxppTl5YaNaEy7c93tiCF+DQl7f69NfNCFFL+TvZNlJhs6rh55LJcgmwMkn2yQ15d5ecBIC3NmwDojmumSbE5aQhfnrwNdi/8/tgyr0FHEFyp5nb2oQCiaTrKcinP1JqkuBPj9XcuwparKj6u0MHzYTcxnmY2nBChuGXRODpawqGnivjf7jg8Aos1KitEHWFq/2b0hVdx2eeY2xlOXippyHaopxzw7Vx9PtAOlA1oNDxN+0XWPgKu7CiIrg8Gr2vN/iavWHajt8ZGhuwILmVb5jqCJzWf6XiS0FqQ/j8Q== X-YMail-OSG: fuYsLdsVM1khnoeL1xS_tyapHmEDMtKqQKNtFPx0xzLSjBNGAbvJBqjOCDiizq0 J2qCZl4ao_NpgH_rWUP2kZWrWP8EmwNqt7qBgHRfK0_CyOiCP2w9CnRgZSgAWsk_fNINNL_q4oj. Nm7NGX1K3nnamJIxaBNSP4uuE1gVDtGUo0M6Dn.2dsYQ4sZ_lcDUwQ3r3QKfEndHAdkCILxJkyuJ RcPFSuNr._e2t.AiIavoHBcXNLJMpYdtAHmhPF4dS1.3KH9UFoI2fU4wsQj8nobQr8B.rh1A_0uu t0pEqFyI4kSfaQMhXc3xc9djAxdgPCasl5uxsBuPSTTS8fH9Vc0G2P5VtnTj_NM6YGPGdm3KCPce h.JfOK6kP1NOnTm_9ODQj.Nov0G2C8TSzIhNbTXahNhhdW2xyO_PwL._u7A48_6czvrULKa60ifs slo0jBanjGdhoHmlR39vcerWHblmZlbbpsgGoyH2hk7_kDojx5jHo3Pu.6SdXgyvTU6gN652DqAH voyG.JORgEaknF2Te6PXHfAIULeYrK_rN_LwDpeuQflgVlhBpfkN0v3WB8qJPsEgpH49Rjq.0xK9 Vwq56Ks4EuSr8qGmcniaXMqUs1DOOUy.faD6UscteFnJ7toCSANtaeLzlWSBySpYgS0hqODhaAip mm2mtJTFUaXzaTNhjRPWkAggx7ClBqhvRhYTxmaJS56ERqkbc4t4kwSngUefh5PEVSVD7_YVhUnq ZdIS0_NhC_SL9ms1J6vA_GlVc4xDKxc_Ej3lPyMi4.oBCJsV._CKurpnduA1AyIFVc6pDZgFcfmX cZ4DPQjU._YjTKOV.vfL6ocnkItT94bZ5pYj6HMIBVnxMmnkoMQSujDSpyyxDU9E_atFYfqxISX3 4U4uUt6v3Hu8Itz_VV_Du3y0ffc1Nbk5DcUfPGZgTu6LaUP1ny5RHsUwsJMBHLIbDjPbxjWz.Vew dS6KDtLC8i3awXf1KL0wb1kPOGoc..1cEFn3RJLpmuPe.7d2628TdYqPmpPwmf.KeEkNdd2AtBuJ h9MDUNXa4xLAmBQrjhDZTIQ1olddcnEEhLFSMG0.vgA0Ce5CgAjcbDopBS5tzPnBHNqVGzps7aso _GOiw_Rk38CeGxamq8YSZiLOEbv3NOLIWEWllwIxyZpT8IEiQNnPQzO8f.2D1yCgXyIPiUv_YOfJ qmd9EMjzw.F69nDKN6i4A_9xQjZFu7ovXWK4.WRG_GOclngK7vGAlMalZk7rqNv1_mrnw8tmBtD6 zcZXxIyy.Q.hUNHYldfjsHEcXSHsPqaHwydmVSceGIclOhL9Aee9T6CciKKwm6OG4pPdhcC3FL9l q0BqSOsVV9hK_rgHNoKIaDcjxZfBNeslvjypk.y5TCwja1lwk4jDW7e_L08.e05pcqhnH07B5ek. eZIUDHleT_63HwDELgg_C3zbpauvwKI4tU793Y5IFI.6jv7qKBUXu.3XypugjrL4_kLr5QKz9sUl eQ8DhQmYN.8SvmlHrhm9d7LNw.YWF8BaOVTe.ZNcTqTLsgGuj8eG.hNZxJSQLGH6DWzDns.YshfY Fe2hxrbcqVMg7NO9c4rbB.v4VsHZu3UKGyY7b7Jy4bc1OVD5r8NmfUTrTkMbi1xCJchn9fqQnRYM bTW82xxUWa2uSFqKyDpH0xx8dspgaab59icmjcEv6w3Z7PBbPLwTWcWKi4tl2_T5Ge6YsILpw0oE .NMWS6AfSN4LpFdXBGO7HEopT_WkcMfdEVhw5f8zhBomjfxoLyvqgTnqR.A.HXA13GJTKTEPSCfG KF3tOFExghoKkmnLmdQVXDK.fS87djmUR98_kubIcyMBvliKdf7ylQGpKKZ7RTZYzH2PTqkFL0Gh CX398ctCotuUU3quVGgdu2ZgC_GiloD0NLIhFMMECh_mOO2JMPp0sthXu.fhS5yOMPv0sGI0E_SV 3jhQk.uOBUT5mr40qLkUyCrgvRlKkpiT2Pti4EcGcYss08SR6Uxe5q2sn8DoqxbKOJRS7iWGZGCB 1OEMpUPVX3HboGlJRCH.qw6DZe69rNkgrpwcTIIDD0kCJRQabbk_RP.LzEOORobodqyjGL1zjZGl zCfHlnpW.2bgILIyZ7nO9rjYAEmUsDz32AukocvoGFGoyqqC1Yp7XHWPPOZ5RwaJR07CifjDMjaT aLteNTVnmN789PeDupAW.eMlUgKzEjO1WDPXoP34BD2MC8FazUsrlm_3t1YlrSHvS6Qlce7xxyEC lGWOc.YUjGsRvZgK25dDpakdWTgHcIjanXNSYS6BMBksVNU03jiOUbGcyTADo1Taa6oOTjFPRP6x LPrgtyOPHkLy44rREUIcSVT.pmcekFQHyhp7gPSASqOs1XANoYg2Pr1pocq2rj5D8WyThNN_EG2Z Pt7PeTNrWy4i7Q.eKN5IFj3UhlBxWmKpFtzvMr3TGrJbkR5igYZq2b4B1JXCvyDzymDeTWDlJWhZ asGzQOQSGz2_mZHy4MY3THMrIuagns8UjcYJvOUXbOBQUl5Uwpb_8fRWtl_d45dsFFCMpIJkP9CV A6Fvji66tABWhyN93KnouD6xIaNID5Rqd4UyZO8MuCGqwUQxlDPV5ZlL.Hn6rJH8lbbpacwrOQ0m 8JaFfAQFIp4AaEP.YirBxlYB2lPLJ32VVmqd5LuDgDq5Ly5.eg8k5i.rMRGB9JQ0ds1_DUc_5gGA R4q8hXzUtANLZw3W1Wur8uGdbC9cY3BO2oY8xD6gvZRP_QimBGXrjh16YFQbY3LqXUbXGnQY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Jun 2021 00:59:01 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 85cdfcc6563d62b9b66b21641ea58be7; Thu, 24 Jun 2021 00:58:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> Date: Wed, 23 Jun 2021 17:58:56 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <43B69E69-AF38-4B50-8018-BCA02A5BBAAA@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9MGH40rpz4jqV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UIC5B/ty; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.32:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Misc notes . . . Looking at your logs, I expect trying to build both llvm10 and rust in parallel is likely to run into resource issues on teh RPi3B+. For builds in that context, it may be better to do something like: # poudriere buld -j main devel/llvm10 # poudriere buld -j main lang/rust # poudriere buld -j main -f SOMEFILE-LISTING-OTHER-ORIGINS based on using ALLOW_MAKE_JOBS=3Dyes . Part of this I based on your on-going llvm10-10.0.1_5 build shows load averages (example): 4.53 4.49 4.40 so all 4 cores are busy with a little backlogged work already. It is also part of the explanation for: bad_C++_code 24:30:53 for both building at the same time vs. bad_C++_code 06:59:12 for only llvm10 building. (I'm not making claims for overall elapsed time.) You wrote in http://www.zefox.org/~bob/readme : MAX_EXECUTION_TIME_PACKAGE=3D432000 (since increased to 1724000, builds = still stop at 24 hours)=20 I think you may have guessed wrong about what MAX_EXECUTION_TIME_PACKAGE covers: it is for after staging the build, just creating the package from the staged material. It is not for the overall time turning the port into a package. The time to build (through staging?) is controlled by something you have left commented out and have not adjusted: # This defines the max time (in seconds) that a command may run for a = build # before it is killed for taking too long. Default: 86400 #MAX_EXECUTION_TIME=3D86400 My prior notes had listed: # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: MAX_EXECUTION_TIME=3D432000 But the figures that I'd used never dealt with something like rust on something like an RPi3B+. So the figure may well be too small even if rust is never built in parallel with anything else. (A similar point goes for all my example MAX_EXECUTION_TIME* figures.) I did do various llvm* builds, but rust is bigger than any one of those by a long shot. Parallel builds of things like llvm10 and rust in significantly overlapping time frames put the load average well over 4 and likely cause periods if significant paging/swapping. This can greatly expand the elapsed-time for the individual jobs (builders). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jun 24 01:15:39 2021 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 21E5611C8BCB for ; Thu, 24 Jun 2021 01:15:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9Mdg34cDz4mkC for ; Thu, 24 Jun 2021 01:15:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624497348; bh=bSmlhP/suG3rs9BbhVeB/P1k5zejGnmisLiIWCqg0fg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y7mqtBr65D+ieZ6JlHNy4dEqA+2cyVGJmhEo4RQMUsMhboRQIzP8FSIKPQ07HZGh17MAY7o3m6bBp5KZkixljzpc0vEXkMF+nKaNLXDdpiniqJ+CAMnKZbMZgKUN+/A980vRUruPc0mF+aN5JYbKaZuKdhBfP8+sQ2h0/9ODn9XliZ0kgQd3vX8HPEyrm1rOCvBtNkdlyNyLkKlv+P8RQeRXXIZECWn0f/6KsKS710yshZXIYIwkBxy0LeQlWxZJIWqsO7wOXOFLdk/qRXxvCv2/J1nwFW5iwDXX+ORdVSGoXXIoalwgmC4T016DrtU/SmaIYbzDQzVig2njgYt7KA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624497348; bh=pjWR/bPNutuwKLGXKmTS+P16zaEEH5mEkg1p658yt1B=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=p1uGxhGBxXB1jXpNK2Q29L3sebAAxto6/paIAJlMf6veIq8hdF+Z7jBdSCHT0E2Axe11poErORogSQluOPc8w4zgKqdv9SQ+PFmcbv42rGlxq0znLyu0uGBhKnrDtF5YV7x9ISuDtLtB/7YuAy+8Ttc6dZxZNL3NiftUXAe2nC2kIH0w9mloGz3160KeBuSfeN0CYAQjY5BLVG3TSqKDInMuOPf9iS5JB2nWpYHWbtlJ6TtIsxD2godmCKSt4Y7Df8ft/A8qlWWboxywWjEVmXgnhQbxlSlgubjfn0P9xmbJYBblMA0vLbGZ8GfP6sRX+W2D54Syt3PHIAc44lLlaQ== X-YMail-OSG: KnafbQUVM1nxw_oo0sLfemtKwyEmHy1pVkdUeujhoJE2ecBavgb0FYj4iTV5LuF k6aXswJkwFWf2cs.i7oT2D6.sP_yCIoCWMFVJQgnOpAEBdPvN.OBs5077IPXa5Ek2ZF9geJdByvO FdIMXLq922h6ByFePUdb26CnpkA36E6ruA_nqWyhzEdMq3h5NA8pp6Zwsr8X6FI1RYlAtB65GVTO su890b9iIt24HLZyCxuYLFUsX6vGGnDf9.RgZM4dg9UyIuvCgBcXq6YC4gczxG54fqzgc50tZwQd QhqeeRA6f8JiJxWm4Z_JaM8gltnTFTcC.wY2wSL_fLn9CKrYMqRPasAAj1QsKHqdns5Qic9cVUwK wFKguTkVfWiE0uH8WfUDcFdwo5Fr9b3DBQ1fjEWL0ao6vxkOtK2QQp2uqQ5xAzM0ql29Bmg14PIV LOHM16fA4gaqk5Qg4xtbskMOOQcT.Ty0IZIbCsoXewmFoTSXS5goKw_ElrvWfHIVTgyQS7yWF__f 9Yv6fPGZOunwgjZw7emr4r6m4xAHQ1ir_wpwi6NQ1iescE_YSyXHQ2C5cjmmM2kQzQWSbKdRBG3p IlSWTRMwzghgIl6dfwRaVrm4VbCllyQVY4WyJFvBaDjiY1Dnjaz.z9WNYRr7a_etmc_112LUNn.. bg43HA7FjKYWJdziz_gvhVv3cJWPY5LCBbtc39ebjWj5YKIIets5jS3L0dl9X8KsKSQHop9NTAYy 02t0qF1XZ31cJPMZOGRZ4J4P6uaUQpFEcLeCjZ6Chux8bHTIooHvhdGTEdNR2MDOaIKe2ipObYyD jU53R8glsSz4U5E_WThXT_NFep9oZa1ECpUOK_UCxsaqAjGXkEw._VHvlGiYtduBHKPKYoys2hZz 5mpZcNN8iOLBznqJ9SfUuVq4H.JPsSVy6WEXJpM8EALFyYrhx66ynZcI2RchrcW3B0UWMUnTq_ke dpKFnH.gXs2.wyacLxLKD7K.e8y4Zjxn4qBAE0s35GJ8rU2Jn2ZfGpSjXhqTfE12q568gAGxDBKq Cd8Uqk08pZK3thSPoIg2XCHi9RCql.rZelCGGUPAha1nwEo6ACQcwYJKGzlFflBlv9dKEcMcQIw4 evo.WMtkBNQrGeUDts6_OC8_c2vrhcTNqJicJzz4r3DZOu.s_5R_Jzg.DDr2FGe19hm_XRay9sQN bxEVG488Mgn1LDXqMZF_MPbE1h.aAvhYYofdr80ovnwMAeG0tCPL_5cDYS6dA_t58_qrDT3FZIhb kJFgIFbpKiNF1CXDy1EnKhG1Aj9NW.TjIRBzERstbeBVsQkhwlPfND2CU_heBEKMBgN9BolzX3YH U748o8HYEIvizonzQFMzUAX.dx0kG5_gQ.C1EMeGO2eceEv1bw41kE7tsTTu0PlUncr8fypgDb9U cSiPdpDZuBS2CfJR6uFZusHQ2bR1VU9u_F2jgxfVPoQGk87MHaSVh7oxiQCP9Yp3J7Z_wvHp3mWh BRZDaazsDLhDgJ0F1xaPELA2SgvvA3WZ2SrdbQGaJttN8sIu8G05A8VMaWhU.NKLROkX9Qyrc2Sl lOnK.Ie_AAjtCTktcbgrRfbhnwyVMtz0EusyEltTTsvOhNlBFhjUK17sv01CgDko5TP5yjWEGn2J Zfh50LYQy2AG3HET5Rxn4ENo9Ts085A.HLownanMiqX5RkIU_PJmxMwoKfJpN0uCmBIGAEd0BUi3 6zOQNdzkWi7E9Yo6hC.nMAQ8XWR2W5igj1hLpIo_a.ltk2JxGXo4tzBFhZizcv.QOQ1zZ8NPhK_c 3fd4vmgJOgzHwKeiDfqUGrx6hhAmBjF5j2KTn_yaemL5RdMdkAfx5rzP5u8.J2SuNHd3ClaXcPqx sp9wlipc2IMeQzDVN2L0QFV8lgO.1Ua6z4rT1a2EpgS8k.HeTrHURwXbXSEyEbLGNtuxKeTD8SKb TyXgImJAnlNmC4fzZUFh8xg5pwJ.67oZFhAmYQ9k1rTrDJBeMLIZQDG.3l1LXoq8.fC0YVhhduKE sJl77IBunCF9xNGtWPXJvr8fRtQls4eGLqo9DPPimG0TE2yGwJ6JjFLEezg6P.Dax_41CY3GYfxe UPsgoOrTtq_CO63WIq3ZUNOfip148wWVZf3I90ClXl.s_64OqR.w9NUy84XzLSI6oS1h2XVRJ7i8 z.X7bCTbbdGqLWgkNKMz0TL2S3icJDsEJFYmt873jq7xaOErTQ.HJ7VfqkhryzgEdtOefsBqPHHp Us7XYBXWY1r9ZA3Nb40RyiGk5YEY1nE6H5zxtbW3W098S3uLjyPdQTBKKIPMie9KbMKARQvxuDqv SrObLjHf7IifijT03yZYgXHoaiOLalg70gVSqem2F2.dcKLLJFIPo7fUEREEhIJvA4Ng0eXN1hCi Yq0D526q_UwRHtnts.QsprBd9kbRPpzQ9XFZCB7lw1D54xte4kBXZdXvcQ4Ax8smE7S33S7HM2M4 y_Q3FtmF3jgHcV6mNEnXlh4g0w.JetNPYjsYJ0OxlYC28CHEp8a5da4dd8Y9I1N175qsKC37ND3V Voi8t8xK.BIVYE9xBq25BVHG.N99LiHAiW41N7WnsQfKmJxEGmVcq8PODhXyHfPIMROKlPCxa5LU 5xCMqaoXP.K4YJudCU4aoKM0Q4OyfOfMv9hEcz7GUoW_ZVAkq1MpgHw20nCF3jdFQ4KSMSmGtOv7 BOVwcy3VQsn9RfK6TFzA0y1deXwvwXayypm1UU8N1J.9kGyyfnTRDJyxBI2rUoy2wIpk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Jun 2021 01:15:48 +0000 Received: by kubenode565.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 03f35d8b0d230afa16500d8b1e713352; Thu, 24 Jun 2021 01:15:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <43B69E69-AF38-4B50-8018-BCA02A5BBAAA@yahoo.com> Date: Wed, 23 Jun 2021 18:15:39 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <43B69E69-AF38-4B50-8018-BCA02A5BBAAA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9Mdg34cDz4mkC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y7mqtBr6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.146:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.146:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-23, at 17:58, Mark Millard wrote: > Misc notes . . . >=20 > Looking at your logs, I expect trying to build both > llvm10 and rust in parallel is likely to run into > resource issues on teh RPi3B+. For builds in that > context, it may be better to do something like: >=20 > # poudriere buld -j main devel/llvm10 > # poudriere buld -j main lang/rust > # poudriere buld -j main -f SOMEFILE-LISTING-OTHER-ORIGINS >=20 > based on using ALLOW_MAKE_JOBS=3Dyes . >=20 > Part of this I based on your on-going llvm10-10.0.1_5 > build shows load averages (example): >=20 > 4.53 4.49 4.40 >=20 > so all 4 cores are busy with a little backlogged work > already. It is also part of the explanation for: >=20 > bad_C++_code 24:30:53 for both building at the same time > vs. > bad_C++_code 06:59:12 for only llvm10 building. >=20 > (I'm not making claims for overall elapsed time.) >=20 > You wrote in http://www.zefox.org/~bob/readme : >=20 > MAX_EXECUTION_TIME_PACKAGE=3D432000 (since increased to 1724000, = builds still stop at 24 hours)=20 >=20 > I think you may have guessed wrong about what > MAX_EXECUTION_TIME_PACKAGE covers: it is for > after staging the build, just creating the package > from the staged material. It is not for the > overall time turning the port into a package. >=20 > The time to build (through staging?) is controlled > by something you have left commented out and have > not adjusted: >=20 > # This defines the max time (in seconds) that a command may run for a = build > # before it is killed for taking too long. Default: 86400 > #MAX_EXECUTION_TIME=3D86400 >=20 > My prior notes had listed: >=20 > # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: > MAX_EXECUTION_TIME=3D432000 >=20 > But the figures that I'd used never dealt with something like > rust on something like an RPi3B+. So the figure may well be > too small even if rust is never built in parallel with anything > else. (A similar point goes for all my example MAX_EXECUTION_TIME* > figures.) I did do various llvm* builds, but rust is bigger than > any one of those by a long shot. >=20 > Parallel builds of things like llvm10 and rust in significantly > overlapping time frames put the load average well over 4 and > likely cause periods if significant paging/swapping. This can > greatly expand the elapsed-time for the individual jobs (builders). >=20 >=20 Just adding another note. QUOTE /usr/src contains a finished buildworld. /usr/ports contains a recently-updated ports tree.=20 # cd /usr/src # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 END QUOTE In the above, /usr/local/poudriere/poudriere-system/ ends up containing a finished buildworld, instead of /usr/src/ containing such. ( /usr/src/ was put to use to do the build. ) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jun 24 01:29:30 2021 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 B5F2811CAAA2 for ; Thu, 24 Jun 2021 01:29:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9MxT4dDMz4prG for ; Thu, 24 Jun 2021 01:29:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624498172; bh=rltkW/mQDzlvKND7LVnv/bl8j4IU/2Yjov+0G9rC8Iw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Wia9OA6g9lQFqAZ+fwT88YeShYi7PNkS0Sj428+oSy97LFutDHvDaynLSO5Guyssbf8luJaGm4YLJyVHYH1gOqdcRgvPx9xhOmiMT//oSK+xmueMG7qOgt8yLrIEx9p+iIurCAQMRqVllMA0E9FmjpnUYqxLA3HAl/EkMmZbXvwIjXliiY+e84HamOic2O6IdBpahxJkQ7JxUf9+26XTxiTWNAMgaU2MgJ0G+Agm4jOaYttSJ1jhkM7LdEPIKldIFVpJ2IZEkni+dfRb8TYknriFjVtf02XMhKc1VPH4zDPU3OiO03e1WmFxPz3U760dtlCZntx8ohrkQsQx1lmwAQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624498172; bh=/EZcbWw4MJSf0grk7mj2xhgUN+WHTSAihRafseoBRqU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rAeksUYH0CjZtw9EtsO8WThZIqzz2T4fnNcbZOFwytrJUqy/KryPn/kuJn/+QTlzwIezmf4h+ma55uzSimLnwSjHOwVJYD1S5KyPejrjgEttTmi3T5BTMNIvh6Jm3qpn7b/DaM+VjxZSNdTsom+Lo7enYR9Khw0s9xO+f2tdUdGHJ4eKjxvu9wXfKd//doGRfS1HwhDWgIlf2ME7MO6Od4XNhvEj/G4D9KNt2rcG9EgerbicF6Wa+lnsGxr/711zSxhJC2vhaP6yBR8hw1FvQ8PduywKzvxEA/L4QpNIWjNww+Lx1CAHEnT22TcMAUcikrX1tq8oA2RSBEoY1HV4BQ== X-YMail-OSG: xHm6.tEVM1nN0xv7QZLMjCjnp9LtqAyyYjSWvPg2d9KXOFd3ylZN.m2rocvhNZX BgEUAfeVucv_7o7oFP8ciSdj7d5DHAxM371BmEt.ZPyXvT4NXAOMJfFRmAfEOSmWTKPIQ3LXok0i gHReG6IQn28oFUWtf5xrqJYSgIbTXC3o.9ti2GPYARZgJdJww5hbkRVb5yCgms3VAo1jDCCMf_ta cRC53KTzPhM5mj8V777rmena95Uv_r9pZv.TMtvfwzuILBVeN7gjLiVXd8m.D9QH7xaAx_lOSGmx PSRUzMH3HIDlHxARw1Q3ESGrEJUNyknAPpSRX5OXhUugVn1igKlRid6qkl2XfUbwifuuA.EYbXf9 J.dXDJ1d7PJf4y8pfGRJtPMtXE0of9j5G15hY4NSX17WWm79nQhBJ8vgEwDTAt2lo2bXkC8eqVBo .aVWfx8tIRAqCrfJMPBD0vZ3qhEhwnAVvLSnOxNyJh7Cmgk5xePspOgqGIcHZSePlhiX.XGJGRo2 P9yYLGm9CZuT1yJOW5I6vfofi81mxV9XrgJw07qLSsZU2FyWoEfUuaIY2oVR1ortw7ypeLRRACwc 68Frd6jLyxFngzGWnOXLlCuUZVTySM0ocA_c7wl7m6hyADeSBhEkSG196SCGLdHZh6T.LBNzsrVZ RXrJqLiLht_lVFqvP2tMmm5Mlf4HgcrnTxEGx6Z9sYTKZ5QzMixGFSFVTuBhdqnBXk9cQzZk32pF OxcmwHh7EvY6zOdUEOHGy_duly5n4qO3IFT_bXH9gQ_8HvYr7QBbYABCTZVZS5De8lNfoJa0pfq0 Hiz2tFlIXEeRFhVNn0EyiAwj3xx8tzE.joEg9F0QigxxNVf6vnVi5kvfTerg_B75elyK9QlS7zFN gvf7PMAviqcAb_tRErYq3PT.Ac.78ceSWQxM8EDGYBMK0k68vC.xHri7xOR2yIdsD8RZtErpuOEw Bjn4a8boTp0wLbJjmCBNB1RVCxIslR0DAIlVtI7eh50v3jO10kx5PW385la4xzA7wNpCApS4UQdo 7IKOYBx3shmYVknXi7TEKDmuG1Y9tRKrK_FNIe15LNz_Y.56G69xUtLqQeRNSSckQZ38G5aAGMFT nRG39PrnI4Ieonzz2PnDuj8pA_kePRBxKkQfomB3sR2c3S97GwP5B8G5iBd1GC_iap8T_D3JaOv4 bMF3YFEQEkKmrB7oMZB3S_d1hPba728iRjILNhRScN7CRQZzxnKwhKgJsmh41gd0pIMDsJtzF_Na N_EBu_WmjjyBaRaY4hbM.Gz9rCU3G1yG0FwgiRXeInuqWyoVXhIHCtDgB6KZGML0UdcTM9WBEfqv 93LN0k.h852hRStSb0ZOtRloy.cQgVVZbw2pYsByktzi1cLCwnFicJ9vYWGCwcp6Wkh7K2TnTmJx P23p2ySR3Co49CKEIdTmOUeqV4OYXrv01HIR9Ia_NgTUm7lgFit9qHaGruJGvWEo1um_nkSy4WhG 5vMVTeNfhzdhW1ZhLCoJ.nduOHNg7LGccSOjnSIQFTBViOPEXu6f5W0K7jNVLrwdT0WWbT.NL0WS P90i.H.AsNWnLFa3d7OE4bbEPbukrIi4cb.6izfDX3DAXkOgRi.0HR4b1xr9oqhbZvbsZsM.r.4B z0u.AbCrrsrvh1HJRpvjnJ3A6vw0QS8ho922lqgHTu5Puqz7Oivx9EF1EAxI3hbQajDB1NZqqKou Q3WCmgMN.whZAgkiN6e_gRDDj.iGShzUHaGm_mikwWcefJaN14Qme.wmyPCfiDHFMFa0bhLmeyqp QwmAANaMuqpwhmtmsrhsEU9x.mch2Px9rV3ErH.GCXXYjcOm1vNz2SsQ0LmrXmGL3gPVXsX5hekn Ev9We4TCCEsxFJykuRUIkTLAO_1uJtMg_g9.Qf7mP.7kRwcma4X39_9be0gpGP2bX4EJ66ii2AZT bASu972dMBbcKNNRewD0dke35pS3A3dRevo_QJC1ey35wW5.fNm8GJmBlAPHUuWPz0s2YPeaX320 FrGcYMN4luLPYUWRZqpALVfRc.HoK50fb0Z_27W9NL3gEEpkApj4JgGxVr1rJx_3xyy6ii_a_Vlw QwAIUjeqCdq8M7sYBavx4QpRlihNNKh_w210ArYPyKuy6izHn3oIaPoz6KPd6RbgmSOALnlq9cPb G1cA8MbvuIhaMVSQNobxMm4vQauVRAaYLkuQzRaiG2QvRC2zrIPWDnJjW1AW25CTM8kPhgAdzBd7 nPXE_EoxAteyXkcoynCAEbS.d1rxJJOrIY9ngVU31wXrtrTr.eXwhFrocDVkVpYYObdL6bIqSmT2 6YR76ZAFgXcvRrVEfZWFHNRckseFVD1HHBw7gzGmgP.mX6myvF9bEqam1vxiZJPI9uEy1JBQ3szy hoBmjcBU7MfpSSBr9Xs1_h0fgm5B1HTxwoWtvFJ.8wJAP6dpGHKgxaZK3n.c_RXDZzbBhgilMdiR 0CDSJADsjyIPdP1akMENMI_c7j5KXvEq7pVY5zcVsPcbxQ.UNHkw8j4Veo1buWf3IVag_mDfzo_G XitN7K0hFyN8ODkVhZ0aIe2nWi2ssW4hssO8L_ufKW2rhhyiOP8mVkUAhX95Ddi1VUHFp2keZQ0C uI4hHRpIOuaML7ZdgjfdZ6DSuR7FvVrxbyXmRhCqvhSQ20AB._ZdbaIoydGs0S_Nweuii7Fb.OWQ QgmuoLqyE8mPvnkQZBN2nPf6Jko3ULPOplZM39Zg8q5JB39ecZvFCl_MiFEb1oW.xfisMxA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Jun 2021 01:29:32 +0000 Received: by kubenode509.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2749683968e7ed4733044e916224186b; Thu, 24 Jun 2021 01:29:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: Date: Wed, 23 Jun 2021 18:29:30 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <3E734886-7D80-4F1B-9CDE-C834BF9428A7@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <43B69E69-AF38-4B50-8018-BCA02A5BBAAA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9MxT4dDMz4prG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Wia9OA6g; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-23, at 18:15, Mark Millard wrote: > On 2021-Jun-23, at 17:58, Mark Millard wrote: >=20 >> Misc notes . . . >>=20 >> Looking at your logs, I expect trying to build both >> llvm10 and rust in parallel is likely to run into >> resource issues on teh RPi3B+. For builds in that >> context, it may be better to do something like: >>=20 >> # poudriere buld -j main devel/llvm10 >> # poudriere buld -j main lang/rust >> # poudriere buld -j main -f SOMEFILE-LISTING-OTHER-ORIGINS >>=20 >> based on using ALLOW_MAKE_JOBS=3Dyes . >>=20 >> Part of this I based on your on-going llvm10-10.0.1_5 >> build shows load averages (example): >>=20 >> 4.53 4.49 4.40 >>=20 >> so all 4 cores are busy with a little backlogged work >> already. It is also part of the explanation for: >>=20 >> bad_C++_code 24:30:53 for both building at the same time >> vs. >> bad_C++_code 06:59:12 for only llvm10 building. >>=20 >> (I'm not making claims for overall elapsed time.) >>=20 >> You wrote in http://www.zefox.org/~bob/readme : >>=20 >> MAX_EXECUTION_TIME_PACKAGE=3D432000 (since increased to 1724000, = builds still stop at 24 hours)=20 >>=20 >> I think you may have guessed wrong about what >> MAX_EXECUTION_TIME_PACKAGE covers: it is for >> after staging the build, just creating the package >> from the staged material. It is not for the >> overall time turning the port into a package. >>=20 >> The time to build (through staging?) is controlled >> by something you have left commented out and have >> not adjusted: >>=20 >> # This defines the max time (in seconds) that a command may run for a = build >> # before it is killed for taking too long. Default: 86400 >> #MAX_EXECUTION_TIME=3D86400 >>=20 >> My prior notes had listed: >>=20 >> # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: >> MAX_EXECUTION_TIME=3D432000 >>=20 >> But the figures that I'd used never dealt with something like >> rust on something like an RPi3B+. So the figure may well be >> too small even if rust is never built in parallel with anything >> else. (A similar point goes for all my example MAX_EXECUTION_TIME* >> figures.) I did do various llvm* builds, but rust is bigger than >> any one of those by a long shot. >>=20 >> Parallel builds of things like llvm10 and rust in significantly >> overlapping time frames put the load average well over 4 and >> likely cause periods if significant paging/swapping. This can >> greatly expand the elapsed-time for the individual jobs (builders). >>=20 >>=20 >=20 > Just adding another note. >=20 > QUOTE > /usr/src contains a finished > buildworld. /usr/ports contains a recently-updated ports tree.=20 >=20 > # cd /usr/src > # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 > # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 > # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 > END QUOTE >=20 > In the above, /usr/local/poudriere/poudriere-system/ ends up = containing > a finished buildworld, instead of /usr/src/ containing such. ( = /usr/src/ > was put to use to do the build. ) >=20 Yet another note: http://www.zefox.org/~bob/ lists: /etc/make.conf But that is the wrong place for a poudriere make.conf . One possibility for a poudriere.d make.conf is: /usr/local/etc/poudriere.d/make.conf But nothing published indicates that you have such. (There are names with a -make.conf suffix that are also possible.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jun 24 04:30:00 2021 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 7ED4811D52F0; Thu, 24 Jun 2021 04:30:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9Rxh1LYtz53gZ; Thu, 24 Jun 2021 04:29:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15O4U1t7088681 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Jun 2021 21:30:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15O4U0Ah088680; Wed, 23 Jun 2021 21:30:00 -0700 (PDT) (envelope-from fbsd) Date: Wed, 23 Jun 2021 21:30:00 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210624043000.GA87740@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> X-Rspamd-Queue-Id: 4G9Rxh1LYtz53gZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote: > On 2021-Jun-23, at 15:28, bob prohaska wrote: > > > On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote: > >> On 2021-Jun-23, at 10:43, bob prohaska wrote: > >> > >>> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote: > >>>> > >>>> Not that it helps much, but: 2779096485 == 0xA5A5A5A5 > >>>> > >>>> It appears that such somehow was involved-in/generated by: > >>>> > >>>> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d > >>>> > >>>> and that lead to the commented out notation in the output, with the "@2779096485" listed in the comment as well. > >>>> > >>> > >>> A Pi4 doing a bulk build of chromium, lxqt and apache has gone far past that > >>> point building llvm10, suggesting the fault lies somewhere in my setup. > >> > >> I'm not so sure of that for the 0xA5A5A5A5u value. You run > >> main [so: 14 at this point]. Is it a debug build? Or a > >> non-debug build? I expect that 0xA5A5A5A5u has some specific > >> debug-build potential meaning. > >> > > The kernel in use is > > FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n247405-8fa5c577de3: Fri Jun 18 17:03:19 PDT 2021 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 > > and it can invoke the debugger using [enter]-tilda-control-b. > > If it was a normal style build of main-n247405-8fa5c577de3 then > both the kernel and world would be debug builds. But it is > possible to explicitly control if MALLOC_PRODUCTION is used > instead and the like, based on how doing the build was configured. > (Lots more can be controlled for the builds.) > > I still can not tell if it was a debug (normal) main build or > not. I would guess it was a normal debug build, no extra > disabling or enabling of such. I didn't do anything intentionally to turn off debug. To all else I plead ignorance 8-) > [snipped for brevity] > > >> For example, 0xA5u byte values might be the value that newly > >> allocated memory is initialized to. Looking . . . man jemalloc > >> (the memory allocator implementation used by FreeBSD) reports: > >> > >> opt.junk (const char *) r- [--enable-fill] > >> Junk filling. If set to ???alloc???, each byte of uninitialized > >> allocated memory will be initialized to 0xa5. If set to ???free???, all > >> deallocated memory will be initialized to 0x5a. If set to ???true???, > >> both allocated and deallocated memory will be initialized, and if > >> set to ???false???, junk filling be disabled entirely. This is intended > >> for debugging and will impact performance negatively. This option > >> is ???false??? by default unless --enable-debug is specified during > >> configuration, in which case it is ???true??? by default. > >> > >> So, if you have junk filling enabled, I expect that you ran > >> into a legitimate defect in the llvm-tblgen in use. Having > >> Junk Filling disabled might be a workaround. > >> > >> There is /etc/malloc.conf as a way of controlling the behavior: > >> > >> ln -s 'junk:false' /usr/local/poudriere/poudriere-system/etc/malloc.conf > >> > >> I suggest you retry building after getting the above in place. > >> If it does not get the 0xA5A5A5A5u value, that would be > >> more evidence of a uninitialized-memory defect in the llvm-tblgen > >> involved. > >> > > Done and running now. In the interim I tried building llvm10 using > > make in /usr/ports, but it failed with another python conflict. > The poudriere session just ended, with a somewhat different error: In file included from /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector .cpp:312: lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:41: error: expected expression /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:99: error: expected expression /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/, ^ 2 errors generated. [ 25% 1396/5364] The last line is included as a fiducial indicator. Two errors instead of four, nothing about AMDGPU. > Intersting. I'm unable to see a: > > /usr/local/poudriere/poudriere-system/etc/malloc.conf > > via what you have published. But I've no clue if such > an odd symbolic link would be expected to show up. > The link seems visible to find and ls: root@www:/usr/local/poudriere # find . -name malloc.conf ./poudriere-system/etc/malloc.conf root@www:/usr/local/poudriere # more ./poudriere-system/etc/malloc.conf ./poudriere-system/etc/malloc.conf: No such file or directory root@www:/usr/local/poudriere # ls -l ./poudriere-system/etc/malloc.conf lrwxr-xr-x 1 root wheel 10 Jun 23 14:27 ./poudriere-system/etc/malloc.conf -> junk:false root@www:/usr/local/poudriere # The link seems invisible to cat and more, reporting "No such file...." I'm not sure what might be profitably tried next..... Suggestions welcome! With my thanks! bob prohaska From nobody Thu Jun 24 06:02:02 2021 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 62CE411D9D51 for ; Thu, 24 Jun 2021 06:02:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9V0104mHz58q6 for ; Thu, 24 Jun 2021 06:02:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624514526; bh=OCeoVEmcxeaozxBepyZ0fVjwf0t+Ksv4AkhT7Yj7PaU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GFFm+AWNWi7spWZRzjEpLpJRiX3wq/DxtApHL3KAFl1bGRwQFmQW0IaisAkb2Cch8umY8n/Z2eNKqrFpMClYoQeSSxqPs1+7LazSJ4Bk8/GtEQBSlwg3eRRbHxcDt/OhCBomUWIKQsFsmCt/h1E8dn8QHeo2lWH6tyVo7tDIUNQxkAq6EiN05nG6vcdMZxkHD3/txC8tywA0wEwraGQDs7LgONqmT/IwN4yiPmNT5i/0z5adfVeQjn/YnG5I2iRD2D7IvZ4xWCIp0xy+6WlXTKVrQBFR78QBKJWgIbskxYPeMyJLsySUKBZs5Iwd7/8IaG0p6y5UyhrOfSQcVVwL6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624514526; bh=APGDAgPXG0KHCh18Xju8q03frQWSmhYBEUgq+krsoeK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ToXHAb1BMthZTbw7KLytI29KIsXa1aNd3jkQvhlS1FNF/ZB4m466xqGCzfAcONqg9pNxY8NEXJe32xd2Y+nb8k5QsQlQOrUlOM00PIkx9wQwpOpRU+J5F4E/5+El+T7HbrJOuvNVoDQxu4kaoeUQH2pevByuN4XvhgdvzrGkh7VJrBJFwbGTOy8voVwu7evCVjS98ZZnXQcqXtqqSPdR9FszKZ4yyyR4VTwbLqku9LEi9AOSeQvwEcC25sq5LUKkIUcypQbUBusKKktxwz3CIvPtN1sWTlELGKiGaaJ81xrGL7MB+b0xQl0Kqyp+B5uK9WbwhMBkoP+9JiR6Ae3cQg== X-YMail-OSG: imhwGekVM1kUEuzpeqGMD90uJplv__s2I9xrsZQ39qXKAN.I.tDTAlod5xp8VBs CUOoGigvcXr8Q0kbmSmRgRbh_Dn0GdAQmJJgVWR65_WFlf9et0k1Fpa2JjVdQl.Jz34Ucsm6V8UC 4EP4VyFwO6f.6cH.Rn0o2VCeV7PoooIH_At17gJ6.YgoHqvwz.H7yPoTLnqcQpPgCmYu3B1On_a5 iIn4JF_UcHshxeeJ0xAziNm.yJHOK5Gery9YUNIUh8gSnuGs0Lcgh3DIaU6w6QtpHVXxjMk4baTb zD1AcysZHTSXT_wVQC67CTFAr83WPKcgfbJpK0BtQLCFAfgyube5lhmFY0JV.XwXqj3kHn7BVnQz gqYpWiKFFO7_xVY6M7V0wq5g_f76pgLvnbSVPa9yd6qgFxm3ThqWGDbzwFdpNuQ7718hf54jn02e ziHMfWWHFpVKxRQGMf2Scbd4BZ.79e7no_m8l7XftCKu4B3LO_yF0c1lr1.DOc6eomQVJArfOnEN _TJit1f2KpSaMqp_edHvMfeNculwxG4.bdZvicqSjqIx3YS.QcQwO41XGih4hDW9E1uuMDu1kSWn FjPmUlNQfEeAHKAx7zYX5psRRjTJnfHSGIR8jHwv8_kyhxhohYb8tK_o0MrYq_XTSw1P8BX.sSRX cVOjSA87gIu3nWttssyE1NRhmjOhu1IQh2oUVuT.UgFtLmg63SSDePCddXTuLQ1O7KddHcd1oN7B dhtWQ0Mm6mdGtqNSicVfYwbkmIP9iAJMz_YhJHyrZUGvSYgvSOHD_9Huv8V03U6tp7AIhKO7FwF9 T08GCtCJXMZv5njt6s_pLWk4gIp_rJ6MTf0e_bN4wWJZyTcNM87DreVwp7u6vfCsYcjx..RpQF6_ acF54rnqp.x6m1O062zBC9qh3wnqXGMXZCuJzWDk.BGejSY2m7nOpJJ0wLE5GIMH3_c7QJugFSmw AicreeaTttG65JICmjPJn6xH7P1hxB9KJyRJOTCzN3fM0x0ft6qJA_MVNIUZ74AyeIQOQO1XnobM WCY8upG1vV5eWkpAozhidrxyyOqwW9oCvYJmohVaAAkGkS2oMeEUTUMvuceXj571L7blbhJttsqF wDWK1wOjt86Nex7mPlFpvff0CR1bJ7ZWUdUxh8s8gcmWlD8t58Zfd8ux2xKHl1vk6jsIBDQ0gh8d uggEK8mHUWxJsYSZVScB9ic4Fdd8hloRqKk_nZX39byt8QsmIWly8c.W_KyPjyMMQOJhZSsYbvKJ qgwfyzvr.72ttJd8tZ8kg8ubk4mWfIse3Nfb6FfbKW20tZ6HULHgFpgP3zfoWv_KLO17gNHwoaJL r4OYZwNl5qPMywlRRK3fd6L8nnKVWhA5fUaG3NV8QzckL2pSeBk0bQPZnhs6FzfQE_q83VQEvyBS JU4sZYy6h311vsbn_3vOXXuGS8Nn3_jmwbCxQ5H05KTdMtuporQvSyJG6ijI30T4PBnhq8pDE_eX qjVKN8JSC081tBOrJnetD012fxyPZnz5B_u9ajdbs7fo_2ZIZfhHsLHDo3MstrgTxK5HiMNVO5rx Axw.tvI2PRSatB4AknkqChGkxwSHcPdhpzQwys3NotB9MxlktUO4OvLtOgooc3Ggyi_9jVMIz09f bWMyo3nVRKacJmWgGWbrVBq5fPfPKo2Q_sR4QJNZFUVi6mCfEOegtKCY.gJwRqgcs5hMxqoiE8NV UMzql12.JIuPfeQwF1Dpt9HKcAxTTK7iBHDkz_iMnDqrxLaIIwdUouDIrj61VPjsHvDtEWivWZQM xg_MboXJqMGTxHBtoLriMiy0Um3mewnt3iZgueSKwbBDqw1XIjVB723twU2YvN_GbZRzcvqwOc2i G_HflXVicGvxtmOdJkly692AR99AgTWtaUemDXGgsfre5AYR7p6UDNzMJP.8FEXUdy0bNPIw0vl6 Phg8tfPAfATJxINv1j1Da1MNUFQMHMre0vhp8xETHWzyzf4UD5wX5Ru3QVXe9NEfq_ff_0H3043B dN0ImaDs2o7BjmAygQiD93WY30YlZNBkakLIqTPheRvSlXj0wr9j4LEiD90hYExniv4pGxJmUshw wsUXvB_EYmhR5FgQkoXsYAhIgS7DxdmwcQKhv5d3ksR9.OvMSe2QAVX1dU.QtFR8.arWLgqGpIwt JCvJ8Aw3rEFHJf_tloVA8ugL2gDPt9KPwXLI2ALLUTK5yT4fQXu6BBoNRAWfDGVBzfXPKFOefaqG 6Nfiuf3Clkmxq4B.0h9ItpXUE1i8ZIvjWCt0pz8uC8OJ3YyQSJMBuLdVZPZGhzVjMAMqiemyQKza DBaPErjMgd6L82hPTFfFcpDx4oM0SbmWXo8m32rVMIla3Yt2KfCQEV9cbZmpZzWsMGqG2JPLX29Z VSfza3.1m0A1UXHdxm8NoPWg21TlBhbjD.hNGTGEOLSb0gODsUExiy.ivuCX97vwvu6HfNzRKYST xZeeYjphh7xpI7FZzLpsOXrZE62tmXq3RxWma2bSTF0eKCZ_bO5YQkVztcsSsqNKIaANT6kwFJCT M5oFlJiHWNWyFpRPBCVgHJJf6Q9aZdMCibmEKFTCndaWRcrIeN4cUe5rkXLFj0QDEiGUe4SGhZdH KbCvQ7o6yCbQNQsRkNjqHWQ8MXTyM65fIy73WcgKLluIpwmAMkecJItDFPowTfByRbfysRZaCvR0 hJTWXxxwwvZNGlU9J2BBeTxbCjcwEY35pYepNTcsoL3MABwK2WYAZfarGBPFJlw7cnO.8p0uX X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Jun 2021 06:02:06 +0000 Received: by kubenode513.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b3aeda0294369b937aab57148fd682dd; Thu, 24 Jun 2021 06:02:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210624043000.GA87740@www.zefox.net> Date: Wed, 23 Jun 2021 23:02:02 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9V0104mHz58q6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-23, at 21:30, bob prohaska wrote: > On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote: >> On 2021-Jun-23, at 15:28, bob prohaska wrote: >> . . . >=20 >>=20 > [snipped for brevity] >>=20 >>>> For example, 0xA5u byte values might be the value that newly >>>> allocated memory is initialized to. Looking . . . man jemalloc >>>> (the memory allocator implementation used by FreeBSD) reports: >>>>=20 >>>> opt.junk (const char *) r- [--enable-fill] >>>> Junk filling. If set to ???alloc???, each byte of = uninitialized >>>> allocated memory will be initialized to 0xa5. If set to = ???free???, all >>>> deallocated memory will be initialized to 0x5a. If set to = ???true???, >>>> both allocated and deallocated memory will be initialized, = and if >>>> set to ???false???, junk filling be disabled entirely. = This is intended >>>> for debugging and will impact performance negatively. This = option >>>> is ???false??? by default unless --enable-debug is = specified during >>>> configuration, in which case it is ???true??? by default. >>>>=20 >>>> So, if you have junk filling enabled, I expect that you ran >>>> into a legitimate defect in the llvm-tblgen in use. Having >>>> Junk Filling disabled might be a workaround. >>>>=20 >>>> There is /etc/malloc.conf as a way of controlling the behavior: >>>>=20 >>>> ln -s 'junk:false' = /usr/local/poudriere/poudriere-system/etc/malloc.conf >>>>=20 >>>> I suggest you retry building after getting the above in place. >>>> If it does not get the 0xA5A5A5A5u value, that would be >>>> more evidence of a uninitialized-memory defect in the llvm-tblgen >>>> involved. >>>>=20 >>> Done and running now. In the interim I tried building llvm10 using >>> make in /usr/ports, but it failed with another python conflict. >>=20 > The poudriere session just ended, with a somewhat different error: >=20 > In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector > .cpp:312: > lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:41: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:99: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > = ^ > 2 errors generated. > [ 25% 1396/5364] >=20 > The last line is included as a fiducial indicator. Two errors instead = of > four, nothing about AMDGPU.=20 You have a prior run that also showed only 2 errors: = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-21= _12h55m51s/logs/errors/llvm10-10.0.1_5.log has: lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, ^ lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:118: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, = ^ 2 errors generated. And a prior one that shows 6 errors but for AArch64 instead of AMDGPU: = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-18= _19h00m47s/logs/errors/llvm10-10.0.1_5.log has: lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, = /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:117: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, = /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, = ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:117: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, = ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:119: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, = ^ 6 errors generated. ninja: build stopped: subcommand failed. *** Error code 1 It appears that the bug does not have reproducible details but all of the examples that do not have junk:false show @2779096485 . (And the only junk:false tried so far has @0 instead.) Something is providing and/or using initialized memory. There is the possibility that swapping out and back in is sometimes not provides pages with the intended content. I state that as an example that we really can not claim to know that llvm-tblgen itself is doing something wrong. I'm not claiming to know what is actually happening. But such would fit with contexts that have more RAM that end up avoiding much of the paging/swapping also not seeing the problem. But as in some past examples, you may have exposed a problem with FreeBSD. >> Intersting. I'm unable to see a: >>=20 >> /usr/local/poudriere/poudriere-system/etc/malloc.conf >>=20 >> via what you have published. But I've no clue if such >> an odd symbolic link would be expected to show up. Still true, but . . . Well, now: http://www.zefox.org/~bob/poudriere/ shows a: junk:false Note that this is at the same level as poudriere-system/ is shown. You might want to look and see if the file system shows such a file at that level as well. This did not show up until after the build attempt had finished from what I can tell. > The link seems visible to find and ls:=20 > root@www:/usr/local/poudriere # find . -name malloc.conf > ./poudriere-system/etc/malloc.conf > root@www:/usr/local/poudriere # more = ./poudriere-system/etc/malloc.conf > ./poudriere-system/etc/malloc.conf: No such file or directory > root@www:/usr/local/poudriere # ls -l = ./poudriere-system/etc/malloc.conf > lrwxr-xr-x 1 root wheel 10 Jun 23 14:27 = ./poudriere-system/etc/malloc.conf -> junk:false > root@www:/usr/local/poudriere #=20 >=20 > The link seems invisible to cat and more, reporting "No such file...." The link is looking for a file called junk:false in the same directory. It is not expected to find such a file. > I'm not sure what might be profitably tried next..... Suggestions = welcome! First off, if the point is to get the RPi3B+ going more than it is to get evidence about the problem, I'd suggest booting an RPi4B with the same media (adjusting config.txt as necessary) and trying the build from that boot. If it builds, the media can be moved back to the RPi3B+ for other activity. The failed vs. built status does give some information about the problem. Built would suggest that paging/swapping was involved in the problem. Failed might suggest otherwise. (I do not know if there would be much paging/sapping, depending on how much RAM the RPi4B had.) One experiment would be to use the same boot media on an RPi4B but that had been told in config.txt to limit itself to 1 GiByte of RAM --and to also try with all the RAM being allowed. If the first fails but the second works, that is probably nice evidence. If both fail, that also is probably nice evidence. The other two combinations are less clear what any implications would be. (I'm not claiming that you have such a RPi4B that can be made available for the duration of such experiments.) Another direction is messy: testing under stable/13 and/or releng/13.0 vintages to see if it is somehow specific to main [so: 14], having an analogous context to what is known to fail under main (as much as reasonable). The RPi4B two-RAM-sizes comparison/contrast type of test could also be used. There is also just repeating with junk:false a couple of times to see if there is evidence of variability like there is for without junk:false. Simplest of the suggested tests, but likely the least informative. None of this would be likely to get close to a short, small test that shows the problem. I've no clue how to target that at this point. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jun 24 16:01:09 2021 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 1FD7E11D53D0; Thu, 24 Jun 2021 16:01:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9lHG4p2Yz4ksc; Thu, 24 Jun 2021 16:01:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15OG19fQ097067 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 24 Jun 2021 09:01:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15OG19iW097066; Thu, 24 Jun 2021 09:01:09 -0700 (PDT) (envelope-from fbsd) Date: Thu, 24 Jun 2021 09:01:09 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210624160109.GB87740@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> X-Rspamd-Queue-Id: 4G9lHG4p2Yz4ksc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N [What about trying a new kernel? details at end] On Wed, Jun 23, 2021 at 11:02:02PM -0700, Mark Millard wrote: > On 2021-Jun-23, at 21:30, bob prohaska wrote: > > > On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote: > >> On 2021-Jun-23, at 15:28, bob prohaska wrote: > >> . . . > > > >> > > [snipped for brevity] > >> > >>>> For example, 0xA5u byte values might be the value that newly > >>>> allocated memory is initialized to. Looking . . . man jemalloc > >>>> (the memory allocator implementation used by FreeBSD) reports: > >>>> > >>>> opt.junk (const char *) r- [--enable-fill] > >>>> Junk filling. If set to ???alloc???, each byte of uninitialized > >>>> allocated memory will be initialized to 0xa5. If set to ???free???, all > >>>> deallocated memory will be initialized to 0x5a. If set to ???true???, > >>>> both allocated and deallocated memory will be initialized, and if > >>>> set to ???false???, junk filling be disabled entirely. This is intended > >>>> for debugging and will impact performance negatively. This option > >>>> is ???false??? by default unless --enable-debug is specified during > >>>> configuration, in which case it is ???true??? by default. > >>>> > >>>> So, if you have junk filling enabled, I expect that you ran > >>>> into a legitimate defect in the llvm-tblgen in use. Having > >>>> Junk Filling disabled might be a workaround. > >>>> > >>>> There is /etc/malloc.conf as a way of controlling the behavior: > >>>> > >>>> ln -s 'junk:false' /usr/local/poudriere/poudriere-system/etc/malloc.conf > >>>> > >>>> I suggest you retry building after getting the above in place. > >>>> If it does not get the 0xA5A5A5A5u value, that would be > >>>> more evidence of a uninitialized-memory defect in the llvm-tblgen > >>>> involved. > >>>> > >>> Done and running now. In the interim I tried building llvm10 using > >>> make in /usr/ports, but it failed with another python conflict. > >> > > The poudriere session just ended, with a somewhat different error: > > > > In file included from /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector > > .cpp:312: > > lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:41: error: expected expression > > /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/, > > ^ > > lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:99: error: expected expression > > /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/, > > ^ > > 2 errors generated. > > [ 25% 1396/5364] > > > > The last line is included as a fiducial indicator. Two errors instead of > > four, nothing about AMDGPU. > > You have a prior run that also showed only 2 errors: > > http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-21_12h55m51s/logs/errors/llvm10-10.0.1_5.log > > has: > > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:50: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, > ^ > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:118: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, > ^ > 2 errors generated. > > And a prior one that shows 6 errors but for AArch64 instead of AMDGPU: > > http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-18_19h00m47s/logs/errors/llvm10-10.0.1_5.log > > has: > > lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:50: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:117: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:50: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:117: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:50: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:119: error: expected expression > /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, > ^ > 6 errors generated. > ninja: build stopped: subcommand failed. > *** Error code 1 > > It appears that the bug does not have reproducible details > but all of the examples that do not have junk:false show > @2779096485 . (And the only junk:false tried so far has @0 > instead.) > > Something is providing and/or using initialized memory. > > There is the possibility that swapping out and back in is > sometimes not provides pages with the intended content. > I state that as an example that we really can not claim > to know that llvm-tblgen itself is doing something wrong. > I'm not claiming to know what is actually happening. But > such would fit with contexts that have more RAM that > end up avoiding much of the paging/swapping also not > seeing the problem. > > But as in some past examples, you may have exposed a > problem with FreeBSD. > > >> Intersting. I'm unable to see a: > >> > >> /usr/local/poudriere/poudriere-system/etc/malloc.conf > >> > >> via what you have published. But I've no clue if such > >> an odd symbolic link would be expected to show up. > > Still true, but . . . > > Well, now: http://www.zefox.org/~bob/poudriere/ > shows a: junk:false > > Note that this is at the same level as poudriere-system/ > is shown. You might want to look and see if the file > system shows such a file at that level as well. > > This did not show up until after the build attempt had > finished from what I can tell. > > > The link seems visible to find and ls: > > root@www:/usr/local/poudriere # find . -name malloc.conf > > ./poudriere-system/etc/malloc.conf > > root@www:/usr/local/poudriere # more ./poudriere-system/etc/malloc.conf > > ./poudriere-system/etc/malloc.conf: No such file or directory > > root@www:/usr/local/poudriere # ls -l ./poudriere-system/etc/malloc.conf > > lrwxr-xr-x 1 root wheel 10 Jun 23 14:27 ./poudriere-system/etc/malloc.conf -> junk:false > > root@www:/usr/local/poudriere # > > > > The link seems invisible to cat and more, reporting "No such file...." > > The link is looking for a file called junk:false in the same > directory. It is not expected to find such a file. > > > I'm not sure what might be profitably tried next..... Suggestions welcome! > > First off, if the point is to get the RPi3B+ going > more than it is to get evidence about the problem, > I'd suggest booting an RPi4B with the same media > (adjusting config.txt as necessary) and trying the > build from that boot. If it builds, the media can > be moved back to the RPi3B+ for other activity. > The failed vs. built status does give some > information about the problem. Built would suggest > that paging/swapping was involved in the problem. > Failed might suggest otherwise. (I do not know > if there would be much paging/sapping, depending on > how much RAM the RPi4B had.) > > One experiment would be to use the same boot media on > an RPi4B but that had been told in config.txt to limit > itself to 1 GiByte of RAM --and to also try with all > the RAM being allowed. If the first fails but the > second works, that is probably nice evidence. If both > fail, that also is probably nice evidence. The other > two combinations are less clear what any implications > would be. > > (I'm not claiming that you have such a RPi4B that can > be made available for the duration of such experiments.) > > Another direction is messy: testing under stable/13 and/or > releng/13.0 vintages to see if it is somehow specific > to main [so: 14], having an analogous context to what is > known to fail under main (as much as reasonable). The > RPi4B two-RAM-sizes comparison/contrast type of test could > also be used. > > There is also just repeating with junk:false a couple of > times to see if there is evidence of variability like > there is for without junk:false. Simplest of the > suggested tests, but likely the least informative. > > None of this would be likely to get close to a short, > small test that shows the problem. I've no clue how > to target that at this point. > How about booting an older kernel so see if that makes a difference? ls -dl /boot/kernel* reports drwxr-xr-x 2 root wheel 13824 Jun 18 18:15 /boot/kernel drwxr-xr-x 2 root wheel 13312 Jan 9 15:57 /boot/kernel.main-c255664-g4d64c7243d26 drwxr-xr-x 2 root wheel 13312 Aug 29 2020 /boot/kernel.mmccam drwxr-xr-x 2 root wheel 13824 Jun 9 18:52 /boot/kernel.old drwxr-xr-x 2 root wheel 13312 Aug 27 2020 /boot/kernel.r364346 drwxr-xr-x 2 root wheel 13312 Aug 29 2020 /boot/kernel.r364895 drwxr-xr-x 2 root wheel 13312 Sep 7 2020 /boot/kernel.r365355 Most of these are probably too old to work at all, but Jun 9 and Jan 9 might possibly work, I'd expect kernel.old to work as well. ISTR the previous success building chromium was early 2021 or before. Thanks for reading, any suggestions appreciated! bob prohaska From nobody Thu Jun 24 17:41:38 2021 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 E9A7611DBF5B for ; Thu, 24 Jun 2021 17:41:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9nWG3wvMz4vF6 for ; Thu, 24 Jun 2021 17:41:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624556504; bh=zRl1/lmJEqLQ1JKkVGKnIr1enDFyaWs4XMgs2UPB1Fc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DcKFSXP0YVLLE3ErraASefyiJAVMKTk2J25T1tVq36G1a/Q47e9VKnPkQ8pvi9fdrCXmZrSKiwXgAASSKx3GdurblC+KYhpyMyzbPO44iPlibGUju/1N9G9YQZtY2liqhplA7aulL0kT85joZo4RvKxMn5HNE8efCROWbx1paXSk8+Fz8vzjjiT0eup1WQzDxXGVqi5fxHRJ+XTm1Cqn9APmulmJeN9KgBMLmMHTMC3Kr8P+NSPYqGtord/uFyrAkpOkd7pHsQG6ZO7IrqoQW0c5iygSuMYFWFuzrLgjoaqEefFM6DNSWl6UYCFFT9F5JUFE1szK3E+9fzBjqR3+cA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624556504; bh=i+AbPbAa3k43J1etJJf7QdiWGS7PP7Ckui0QVEOn90A=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mB8o794QjF6Etfka4NsNa7ksBd5a4stWOM7JNaHzPpsq8jN+CCYvlIMxQXTUb7QiesbIqld2Lv59e7ktm2A1afBIxEIczqldkDdO8XXE5baZAlz1787MBAIVa/LEwjnv8xM0rqowGpXOXU+YUHI6BhcO6rw4+CyZm6T3T4ZSSOhQ8Ms0++J+++3+lE1rFeQIWoIzjPrK050V/6zqiq+5PlozYUyT2Z/m0BAs4QX85av+w8hi2GaRJVmyPV2AhXDkckotyZBpUTBRuqQOSnNzLMJ7udWgmQ6oJhu3LBvMo8Wm5uophNG7Z6Sp7lfJrBrHwnaaursLkTPfzNTHl08OGQ== X-YMail-OSG: gl9d1NYVM1kU0jZLRLu7.LQILrimk8DP8C4AhrPNaeA_OXq13RK9tiFVWQSYJlP G88bIwdYdVrD6sp11ml5rNzl6AWcVdhfZ9hIrtzaRD4uMi67yMU5TA7bHwMwq4tb9Itl3Povmxwh M2UQid0T.Wk796m1CTEs8igZnGaWZtan..vHffDf.TUEMACGojdMf.cGis1Hypo4IeAzCe0ezZmD iJ6mGgXoJMwMErAR1RWeufg5Pt9bsk1EnaPYXPMg.G0evqBkUEguIxO_FuQ6r1lzET0uxsYUgne1 7jrKMQPmtWl0QIVsFJfLr92rX7LOUyAs1f5.uk_20TF.OGwGQfis_ta6cpna3M6Jyyx.JgXuWpAO uemsqW19YHkyB7mNcRVR7qhPbgvUaJFYwMe9GLLSpdCj.ay2NcLBtzKmGvZ3zbGwmucMFmFr2DH0 Grje_38j5JWhIEDdgXcG7NGJxyg8jZyIzVTrCnojlghnZSdeVWbASjZva69z137j0PnTAZj2xvW2 iVnrF9afMFhgE_chtIgGq6I9tvm0GK91OTjSJ9In6XIijcHOg_3U6x36tQd50JDO6vJmOquATeSB k92zseYd1scwerRzgDmTKQvJM71s9StV47yxAnQ694UtPvbITPXEg_uPSJQoG7E8S4BVOpBaCbQp 05XcimpCzXn.blL3SvKJYl6WOwzibXPGY6yde7y1u42YM341E5LLwGH84BgcNZCsz9kfDJHIe_.b _miR57nflN_BTbpH7YA_zcb_KBA5KYUVHRjQsyWnD7uiy2CKF1CTkjDikCFLRNyYeqhCo0tyiv3v Vwvtt5x._ZyG2pBQ0v4jtjDF57RkKXvoMI6dT3b1sZjdog.6cvfFXfjaxaGieiLrPgZq_OW9yri8 rsXN3JoQTeGsFeC_n_45R4ZnpFoxrtePPLJZf1F1rF08S.BOvG02GIs8ML30czhl7YNCpPYGtdTS .qFEMjR5v6hOM4emJIzDRCgwHyBdQ0v.6X_k5E6H3n.3aPeKI31DATEBA1iQnQ.D.2.dc_YdP37S mx.iksgr_zYivrLaGtST70p4aOVvz7wCLDvq0nMXUQif34BbuviXT12tOrMD9ZtsL9Ud..md.I_X 6rJOb2zvnABxNfuOCRiQC8UPQFDpVQHF.DqzJXjo1l7DyEF4GV2NqKQgCVfXzTG..pMcFpTf_PC9 3817JPNn5gYInAI22bzpCBVLus_9_M9ezK1_dPKFbfeSOiGW7OwonCnrFoocW8_2RCoLRBD4gW3a z1hfFWdxcaoEHbYQAwLo5ZIKAS2gjkuAqciW9TW3nu_8xVebzvR4_PnCMIHLQbRHNB4lAoyQix38 wqnxPqgG4FAcjS4SM9kN60g.XcOd7rNGKkwKIhn.xk364Ss0F_8q8TPjl8M_4MOqRcHR3YBfe88c VJeeqQZwnr574uIdhvNpZgQuP3DwebTRuSL3cmt4l3Ia.SHd_eEyukDEx7wT8k9Jnlr.4yzCdbRd CfzOCDCDny92tWC8acZaLUA4iHnrM9QRQ07tEPqoDbUUXrsvNg8D6FiVVffowse45BPvDlX.dflG AG_G3A13H741MZG3eRM82ay7Zs1tnKh.0AiEbOg3ONIqffmTAPZZ4s59lDPDXHYt5hBMywI3D_Q9 3b9BjZpTZh3g.dWJrdIh5NANXhvNXmhaQKrrw0AFmL_PLenxFgYP4vlk3otrOlhHPVljP7b5aRrF 3Qku1gQTlTCPIa39HCYSmSxS0Q5bsGEMa0xyxaI7TaVr7rpecEpcNzlxshAkHPTMzZPgKeVDbnFa lj1A17EWZLNMGR.SzIfytlzHUT4gZDq5TH8wju1yVrHhsVBLU3PWb447TccDlmeOlEk4Qw0Fr26V VVQTY9Wgt7Hvvzn0ZVp4NNsYNp1n4bVAkcKBsX9KhDKJRnfAGjEamHoGfaPc7wEqU0386hZm2qZ9 eCt63lV_tv9gJxJ5Vi225Etw9xcP2wnc.Bq2m6lrVzHxT9NWownCIO.cgZVlBqsiaoxNwD8Tq875 6E_x5kpOYKBLoEW9QAavE.EAOMcmPKF.AZhBBZQuhmQ6eGQABXJ.2y1FOjRazer4QF5gjfzCD44i epI2SxyhuzbTxg.kx3.Jwc7j0IeB8bxRIgJzkAn4ma34gaash7_LAU34OpJFmfYF.jxj64QxZcX4 XshHf3b5hbuL.NI4eGnqSwF4NE.ykOznFW50ZS1tmPKWDlE.vrVZYGxhvTld_hlVayYCJ5u59OIZ v_BGA3z2r3OsAwRo_p4psfxuYQyx.2cIYYFj54CnMI0c_1LZ7m3wrNZhpY6IIP4oAwxgZ25tEn31 Y00YlJ8PAeeRGwrvq_ea7e6.8SpowwJTQ77U1LJyls4N8fWZGUZnDensw_GWqemU9q52UI5SIUy5 8b6k2ORYiKRL1RwLNWHXqq1x.3oosv62ajwaWVvv.Noj5PArkJboZDhext6C9D4WozNx8vkzf3p5 HF5fjIOe0SbnVck4x0_RIZ_ZppLWIdAIKKaqxFsw3NhDuBpgHig9lhd.cbK6CbSEW78tqXD21I9a QKUxyZd8hJmWaxtC4u6PVVrmG_qvLIg4Q6z62MnTvEGpFPREJ3EFcbK9ahu9VgMS8FkYcf58QNIm 8lc4maUyQudBfWSgJrW3u0Vqn8Npafo8ZQmGzNSg5IwzmV4Tl4lbnha8xubM8Nwsjc2sSbU9mX5c aaxiuFbBVjXUgQ8aj2FNPsXIvXVGMfFJsQajj.yrSBgGa4M8CpDba3yD32ZNTszdTusY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Jun 2021 17:41:44 +0000 Received: by kubenode573.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a190627fc72cd8f070d3662f15a06f70; Thu, 24 Jun 2021 17:41:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210624160109.GB87740@www.zefox.net> Date: Thu, 24 Jun 2021 10:41:38 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9nWG3wvMz4vF6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-24, at 09:01, bob prohaska wrote: > [What about trying a new kernel? details at end] > On Wed, Jun 23, 2021 at 11:02:02PM -0700, Mark Millard wrote: >> On 2021-Jun-23, at 21:30, bob prohaska wrote: >>=20 >>> On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote: >>>> On 2021-Jun-23, at 15:28, bob prohaska = wrote: >>>> . . . >>>=20 >>>>=20 >>> [snipped for brevity] >>>>=20 >>>>>> For example, 0xA5u byte values might be the value that newly >>>>>> allocated memory is initialized to. Looking . . . man jemalloc >>>>>> (the memory allocator implementation used by FreeBSD) reports: >>>>>>=20 >>>>>> opt.junk (const char *) r- [--enable-fill] >>>>>> Junk filling. If set to ???alloc???, each byte of = uninitialized >>>>>> allocated memory will be initialized to 0xa5. If set to = ???free???, all >>>>>> deallocated memory will be initialized to 0x5a. If set to = ???true???, >>>>>> both allocated and deallocated memory will be = initialized, and if >>>>>> set to ???false???, junk filling be disabled entirely. = This is intended >>>>>> for debugging and will impact performance negatively. = This option >>>>>> is ???false??? by default unless --enable-debug is = specified during >>>>>> configuration, in which case it is ???true??? by default. >>>>>>=20 >>>>>> So, if you have junk filling enabled, I expect that you ran >>>>>> into a legitimate defect in the llvm-tblgen in use. Having >>>>>> Junk Filling disabled might be a workaround. >>>>>>=20 >>>>>> There is /etc/malloc.conf as a way of controlling the behavior: >>>>>>=20 >>>>>> ln -s 'junk:false' = /usr/local/poudriere/poudriere-system/etc/malloc.conf >>>>>>=20 >>>>>> I suggest you retry building after getting the above in place. >>>>>> If it does not get the 0xA5A5A5A5u value, that would be >>>>>> more evidence of a uninitialized-memory defect in the llvm-tblgen >>>>>> involved. >>>>>>=20 >>>>> Done and running now. In the interim I tried building llvm10 using >>>>> make in /usr/ports, but it failed with another python conflict. >>>>=20 >>> The poudriere session just ended, with a somewhat different error: >>>=20 >>> In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector >>> .cpp:312: >>> lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:41: error: expected = expression >>> /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >>> ^ >>> lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:99: error: expected = expression >>> /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >>> = ^ >>> 2 errors generated. >>> [ 25% 1396/5364] >>>=20 >>> The last line is included as a fiducial indicator. Two errors = instead of >>> four, nothing about AMDGPU.=20 >>=20 >> You have a prior run that also showed only 2 errors: >>=20 >> = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-21= _12h55m51s/logs/errors/llvm10-10.0.1_5.log >>=20 >> has: >>=20 >> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:50: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, >> ^ >> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:118: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, >> = ^ >> 2 errors generated. >>=20 >> And a prior one that shows 6 errors but for AArch64 instead of = AMDGPU: >>=20 >> = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-18= _19h00m47s/logs/errors/llvm10-10.0.1_5.log >>=20 >> has: >>=20 >> lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:50: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, = /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:117: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, = /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, >> = ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:50: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:117: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, >> = ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:50: error: expected = expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:119: error: = expected expression >> /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, >> = ^ >> 6 errors generated. >> ninja: build stopped: subcommand failed. >> *** Error code 1 >>=20 >> It appears that the bug does not have reproducible details >> but all of the examples that do not have junk:false show >> @2779096485 . (And the only junk:false tried so far has @0 >> instead.) >>=20 >> Something is providing and/or using initialized memory. >>=20 >> There is the possibility that swapping out and back in is >> sometimes not provides pages with the intended content. >> I state that as an example that we really can not claim >> to know that llvm-tblgen itself is doing something wrong. >> I'm not claiming to know what is actually happening. But >> such would fit with contexts that have more RAM that >> end up avoiding much of the paging/swapping also not >> seeing the problem. >>=20 >> But as in some past examples, you may have exposed a >> problem with FreeBSD. >>=20 >>>> Intersting. I'm unable to see a: >>>>=20 >>>> /usr/local/poudriere/poudriere-system/etc/malloc.conf >>>>=20 >>>> via what you have published. But I've no clue if such >>>> an odd symbolic link would be expected to show up. >>=20 >> Still true, but . . . >>=20 >> Well, now: http://www.zefox.org/~bob/poudriere/ >> shows a: junk:false >>=20 >> Note that this is at the same level as poudriere-system/ >> is shown. You might want to look and see if the file >> system shows such a file at that level as well. >>=20 >> This did not show up until after the build attempt had >> finished from what I can tell. >>=20 >>> The link seems visible to find and ls:=20 >>> root@www:/usr/local/poudriere # find . -name malloc.conf >>> ./poudriere-system/etc/malloc.conf >>> root@www:/usr/local/poudriere # more = ./poudriere-system/etc/malloc.conf >>> ./poudriere-system/etc/malloc.conf: No such file or directory >>> root@www:/usr/local/poudriere # ls -l = ./poudriere-system/etc/malloc.conf >>> lrwxr-xr-x 1 root wheel 10 Jun 23 14:27 = ./poudriere-system/etc/malloc.conf -> junk:false >>> root@www:/usr/local/poudriere #=20 >>>=20 >>> The link seems invisible to cat and more, reporting "No such = file...." >>=20 >> The link is looking for a file called junk:false in the same >> directory. It is not expected to find such a file. >>=20 >>> I'm not sure what might be profitably tried next..... Suggestions = welcome! >>=20 >> First off, if the point is to get the RPi3B+ going >> more than it is to get evidence about the problem, >> I'd suggest booting an RPi4B with the same media >> (adjusting config.txt as necessary) and trying the >> build from that boot. If it builds, the media can >> be moved back to the RPi3B+ for other activity. >> The failed vs. built status does give some >> information about the problem. Built would suggest >> that paging/swapping was involved in the problem. >> Failed might suggest otherwise. (I do not know >> if there would be much paging/sapping, depending on >> how much RAM the RPi4B had.) >>=20 >> One experiment would be to use the same boot media on >> an RPi4B but that had been told in config.txt to limit >> itself to 1 GiByte of RAM --and to also try with all >> the RAM being allowed. If the first fails but the >> second works, that is probably nice evidence. If both >> fail, that also is probably nice evidence. The other >> two combinations are less clear what any implications >> would be. >>=20 >> (I'm not claiming that you have such a RPi4B that can >> be made available for the duration of such experiments.) >>=20 >> Another direction is messy: testing under stable/13 and/or >> releng/13.0 vintages to see if it is somehow specific >> to main [so: 14], having an analogous context to what is >> known to fail under main (as much as reasonable). The >> RPi4B two-RAM-sizes comparison/contrast type of test could >> also be used. >>=20 >> There is also just repeating with junk:false a couple of >> times to see if there is evidence of variability like >> there is for without junk:false. Simplest of the >> suggested tests, but likely the least informative. >>=20 >> None of this would be likely to get close to a short, >> small test that shows the problem. I've no clue how >> to target that at this point. >>=20 > How about booting an older kernel so see if that makes a difference? An interesting point that I'd not thought about was that if paging/swapping (or other I/O) was a source of the problem, then, not only world, but also kernel code would have to be tracking the status of /etc/malloc.conf . It is not obvious to me that the kernel would directly track that. But if the kernel was not replacing the content of some pages like it should, it might be that we are just seeing the world code's prior initialization of the memory. > ls -dl /boot/kernel* reports > drwxr-xr-x 2 root wheel 13824 Jun 18 18:15 /boot/kernel > drwxr-xr-x 2 root wheel 13312 Jan 9 15:57 = /boot/kernel.main-c255664-g4d64c7243d26 > drwxr-xr-x 2 root wheel 13312 Aug 29 2020 /boot/kernel.mmccam > drwxr-xr-x 2 root wheel 13824 Jun 9 18:52 /boot/kernel.old > drwxr-xr-x 2 root wheel 13312 Aug 27 2020 /boot/kernel.r364346 > drwxr-xr-x 2 root wheel 13312 Aug 29 2020 /boot/kernel.r364895 > drwxr-xr-x 2 root wheel 13312 Sep 7 2020 /boot/kernel.r365355 >=20 > Most of these are probably too old to work at all, but Jun 9 and Jan 9 > might possibly work, I'd expect kernel.old to work as well. ISTR the > previous success building chromium was early 2021 or before.=20 >=20 I'll note that: QUOTE (from 2021-06-12 01:53:02 +0000 commit) param.h: Bump __FreeBSD_version to 1400022 Commit e1a907a25cfa changed the internal KAPI between the krpc and nfsserver. As such, both modules must be rebuilt from sources. Bump __FreeBSD_version to 1400022. END QUOTE So: Even going back to June 9 may messed up nfs use. (I've no clue what services you depend on or in what contexts.) You might need to disable nfs even trying to start at the next boot before booting into such an older kernel. Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got #define __FreeBSD_version 1400000 back on Jan-22. Running newer worlds on older kernels is not supported. Generally folks to not track the KBI changes vs. the consequences of not having the right KBI. This makes interpreting results difficult even when it appears to work. There can be mixes like NFS not working but other things working. There could be corruptions but such may not be likely. Do you have what you consider sufficient backups it case things get messed up? (That might be the status of being okay with starting over if something really bad happens.) If you try the combination you might want to review the boot messages for any evidence of problems to worry about before starting a poudriere run or otherwise causing the system to be busy (or even, just leaving it running but basically idle). If the world/kernel combination happened to work well for the specific activity, I do think the experiment could be useful. But, if it were me, I'd not want to run that way beyond the experiment(s), even if the specific problem seems to go away. If anything else odd happens with an old kernel in use, interpreting the result usefully will be unlikely. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jun 25 00:16:51 2021 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 5925D11C9A5A; Fri, 25 Jun 2021 00:16:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9yH80PB1z4ZZP; Fri, 25 Jun 2021 00:16:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15P0GpaN001542 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 24 Jun 2021 17:16:52 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15P0Gpml001541; Thu, 24 Jun 2021 17:16:51 -0700 (PDT) (envelope-from fbsd) Date: Thu, 24 Jun 2021 17:16:51 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210625001651.GA98214@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> X-Rspamd-Queue-Id: 4G9yH80PB1z4ZZP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote: [huge snip] >=20 > So: Even going back to June 9 may messed up nfs > use. (I've no clue what services you depend on > or in what contexts.) You might need to disable > nfs even trying to start at the next boot before > booting into such an older kernel. No NFS involved. Right now the machine is running FreeBSD 13.0-CURRENT #5 main-c255664-g4d64c7243d26: Sat Jan 9 11:27:58 PST= 2021 bob@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MM= CCAM arm64 and repeating the previous attempt to build devel/llvm10 with no other intentional changes.=20 >=20 > Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got > #define __FreeBSD_version 1400000 back on Jan-22. >=20 > Running newer worlds on older kernels is not supported. > Generally folks to not track the KBI changes vs. the > consequences of not having the right KBI. This makes > interpreting results difficult even when it appears to > work. There can be mixes like NFS not working but other > things working. There could be corruptions but such > may not be likely. Do you have what you consider > sufficient backups it case things get messed up? (That > might be the status of being okay with starting over > if something really bad happens.) > No backups, but I'm not averse to starting from scratch on this particular machine. As it happens, the poudriere session ended much as before: FAILED: lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64Instruc= tionSelector.cpp.o=20 /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT= _MACROS -Ilib/Target/AArch64 -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10= =2E0.1.src/lib/Target/AArch64 -Iinclude -I/wrkdirs/usr/ports/devel/llvm10/w= ork/llvm-10.0.1.src/include -O2 -pipe -DNDEBUG -fstack-protector-strong -is= ystem /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem /usr/local= /include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-time -Werror=3Dun= guarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-string= s -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimpli= cit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-d= tor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffun= ction-sections -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong = -isystem /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem /usr/lo= cal/include -fvisibility=3Dhidden -fno-exceptions -std=3Dc++14 -MD -MT lib= /Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelecto= r.cpp.o -MF lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64Ins= tructionSelector.cpp.o.d -o lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGe= n.dir/AArch64InstructionSelector.cpp.o -c /wrkdirs/usr/ports/devel/llvm10/w= ork/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector.cpp In file included from /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/= lib/Target/AArch64/AArch64InstructionSelector.cpp:312: lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:41: error: expected expre= ssion /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64= ::FPR64RegClassID: @0*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected expre= ssion /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64= ::FPR64RegClassID: @0*/, = ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected expre= ssion /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::= FPR64RegClassID: @0*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: error: expected expre= ssion /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::= FPR64RegClassID: @0*/, = ^ 4 errors generated. [ 25% 1396/5364] Not sure what to try next. Thanks for reading! bob prohaska =20 From nobody Fri Jun 25 00:54:36 2021 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 3C9F411CBA66 for ; Fri, 25 Jun 2021 00:54:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9z6l6J7fz4cpK for ; Fri, 25 Jun 2021 00:54:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624582478; bh=KHwk3tLIZPNF72wTaSGs6LgL/R6ib0l7gMycxp5XRok=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=V5zuVSPxjfuwg1n6UP30jdOd/AZvq96POz8RV5IgRjfGUwP/A44INK9YfdiN3Zy5P/WtWo0tfY7yqvG1ohVRulPtapsaLco6p/gkL6eJhLZ6lVZCLzP5lvhm1hUXM+lQd7VEQ9DO8qljVSrfxmxVj2dpaXigSBTVPLsmyEm1CmJaBUQu36l85QTnogMJhr+w1SwV21emmSyTaw31XUxDrcLm2mp9rfpbCXiSAVZeQgn3hz51SZSPC4UB/bToccwwHHCMAQQtjnPDY8ifUTwNSrwhCrBUv/zI1EwVCGK1+FpamnsyiuwlR4wXCDhD6i1UjMmqyaJbBnRNOS3vcm8jag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624582478; bh=k9j6vxqNoz/uek53lL8Sb1LQRl18G9uZ2RByAAK+deE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uEHs6cWhLLtcLxe14pBY36qgRMAjsamZjPiREwLNnF0efF7ccSHDHQ4HgBYeKCBi6pKlfXhAR4rgYqnf1adprqgNvUZoYMVdeJaoLytnMWtazmR+oBZxFcW321Yvt7AjW0n+JmJVf4G8iCYezS3iw5R7KgZRRwjlPq6j4caIgtLei6XMz7hj4A2nant7nloJVZl2aY2r5OEi22EqFdBDrCnDcHBNiS6deS4d7tXIYS89J7f/aIA0NpM9dbfDcUTsoR3tVvMXejJ9pNeQ38YL+mNrsBmfUjhBQCTo3vKAS4QoY7QIJqz1Zqb236OL3Kd8x6KIP7Egunm7w+UUGqoK9Q== X-YMail-OSG: 8xsm7WMVM1kf8Ckp_VLYGK7X2KH8Zk9wV59npVk1BZFdWOYCZBa6dbyZkmKkhKW e90sCdJeXLlPRTwOo2VaKJqcXWKmksqPfi4qJ.HovEWd4eL7e316Qc.eP4WtR_iHgpu039EJluJ4 Qwo6qNJU.Hsc2eyJlyGp45ifzrOIPHfgveHTUhGKaXsXIipD5KgaWxq7186V_TAGo3lGnyGZwXY0 9Y03GVqaSFQmT24a7Vu2jglDSKSAAjpdXs3vgMcacyQ6oOTbKPa3YZyNFjzpNkqDzHNeu1Mvk5wn 1j7aSmqpP61P6t2dBlSgwNSXYJo6bj64TcM1WQpPgIkFC1DlMVdBGlKKr49t4Z2t7K8SxFJBpvVs Su80gTtz3aiQXhhe_a5RkyreXVdUWAvEEkdtbPYgrs5PcC2y9RmM2QslVtMKBfKmF1Pff1wGTUDY 0Bo.qgjXalZdwEPUrkAxJL30IkCNqurmFtq99LKgZkTfwJ0X7f45a2o0xbjIFwFuAgaqEMkeqDCl K3sanCHaSclws11TaR2kOMST0TJakquoFHBSGULysuQCtVQdH2aFcpJsecsdG1bw.0U5w0krWnab zquoQI1LRPjNebQL31uRASv_mcjAfEsz7trxpAVAMcobRjy6Y7zp5j.8B7Ud8aI8bWbiw2jLmspA .w8byLokQoh1fAzriSiVtGymu5ORugMchze5jUR6IJJMkrQpHHywHs0U8fIqDrssChGowjyrTlJZ Gpv9j82djb0RGoWTyreJjv_aQAY8.Fs_XqAeMRWdeIGWGIj_0nnpO1ne_8enX3Nqv9wgoWPNfjuW .YhWg_YhYyZSosLFyfbWqImMR4jkMZ3xopsCGnByWEDzMHoxWbT_0qYLJJlhaW_KcTS_sR3uiq8S Na1oeIigQHj3Ui8u_UuY5lSPWHiu.EhQS2s8PXF7b5KsVgTb.ZuKVUy0pw.uf2VVo6OkVD6s478M 5tt1z_tJFwTRA5kd2TSZYt2KP.l3zhnSaGEUuufNdJemnMGIbYfUgFWx6euivhIDhgftP_gyrcj5 7_9vrEhM4NuJkM9rhchDY0UrROEjw8Qfn3JfxOs72yiX7l98l0CXYnRxb_nFzF9O6rUcXb9ZaBia VQIe3eIUsNRweDD4p_ow5awblb63RY2Ya5fqqDTQkvnALbjgVFzE5u5AvprdWV2ulezHnuuZTlvr YwKNRhCa63dkMFCcNorO301N2UELBHWEfzkqtBwfyes7wdwXZD4Z5fcQ9F15RwfVpKK5yGmsrTuA BjNCg4vMu4lMMdSHqgYP4SdmkHhUltDfHcmF3YMEpOXn.vzqmfA94ZARHqDjuXOgg3wX04pzz3EN M5QUNuh7SUUGwYiHRg3wa4doHmGJCJZUmaYTzTfIjpExnMeE2oqeNMFPowNq_6pw8FYFwaBGCFl8 MW25UTCpoG.dWlp1fqPZDoi7uHezMBOvjjW_ZHrElHUKMpPoggFChnc2pX3MIVQbMg9giGBjWTzT YsW3yJsQ1NABne8zHZpa2rK1TBKK0S4HZmH5wKyMPRWbLn_K9FXf.s0OLR98FUewTe3I9bnWJ2rf IZ0DkXTAURiaspwPSb7vy9ejB_Jze8rEotqtlWzLsR5wHW90wZVTGuQbzecYR7UzQnciPEgFdK2a CEWYkdq_.Pd6e1dAzYL9Aj5Jmj1yYdBq7oyFX2iz2wK9fW28l5L3byXp2v3pt14A_H_JU5ijHp99 2T1ON6RJ9Tec_49RpJOVhC7sx0YzT7OcIBK3g6OWvpVmPrq6JRZnRXpkNXkS3EAa_QNJrjdLMSj3 JAMqeQrRpHyM0tpB1xiNd7mAkn14jrudI0_kGTQoeG3w8SjriKDdKjrlBPzdfkhHj3bdE12lFVUQ 2vCshXNrZobFRRVIi4zDOvlOKzCuVm0Sxk3.DN2VGgTU3LCvuDuOyiBR1GrxeQV1bsHu3KrE9Aeu 4129lGbMJTTPa6RTe0.dWuy4D7pNj4qX7xFc5FgIZ41O_8SSQrFL8ppbwzCGFUKwdjr7DY8e4OUy mxkDWBZYM2f1vX2FYPIl_CnQ4GPYGkJU78SmI81P6MNsmoYJlqTXB3LLjnJM4nlpXnZjlhmJj6kE eq2uJPjTEBOmskBp8cL8q_pmWWZlaHlAlmmpMYYv_rcb580EvCMW7cBD6jTurxJnkElB7FT.AOFw o2o8vXMohl17KVD7WaYdA1a.SgMRCK5lv178oGchM8iUx47_N1YLISKfxrMy5teJDgrSazKC8xrw SwDqHWJJ_D1LCFX8hTKMOSvyvgcgqStxRECAtH.u8rnuVqd5pgtYhank3S8aJ973MWZzEX0PTjqC 1GKhgm6WLTCES_MJMlRlZEl3KdGuLZOXVxda0n1k53.KE_HMC9jDWtS_taRlocJy0TskPh8OHpwm 4sLWsyDZVSAC6txxV9tgg_t7qYmjRcR51GWRTAjaVOPXXEum3efhFesQz_4a1kbO6Mqjqy5Vp5Tt D_KXDiIkv2Hee2zZaFXb_AsDOZFdHvGGFzsLd2.AOu6pvGC7KSEMYyVOe5U6bBx2GgFoR.bFbTWn tR9cR6sN0_myox3FzayCfHTSELxFU37gCzNBArUzmjXDPo6wFMVfjwKqK5c8jOHcIrYXDnImNcw1 DlzQlcij_9SWaaz36XkQ1rkaTBWRJ9e_bBoE97KtYWSR3eTUEZtBKv3JMTcMA5JyXIHG8J6y.lns ocur45yQOxM.DO_6ZwQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 25 Jun 2021 00:54:38 +0000 Received: by kubenode501.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12f4d4b3260412e275d1742b4b17ebe8; Fri, 25 Jun 2021 00:54:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210625001651.GA98214@www.zefox.net> Date: Thu, 24 Jun 2021 17:54:36 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9z6l6J7fz4cpK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-24, at 17:16, bob prohaska wrote: > On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote: > [huge snip] >>=20 >> So: Even going back to June 9 may messed up nfs >> use. (I've no clue what services you depend on >> or in what contexts.) You might need to disable >> nfs even trying to start at the next boot before >> booting into such an older kernel. >=20 > No NFS involved. Right now the machine is running > FreeBSD 13.0-CURRENT #5 main-c255664-g4d64c7243d26: Sat Jan 9 = 11:27:58 PST 2021 > = bob@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCA= M arm64 I'll note that the output of -apKU fpr uname: # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #3 = stable/13-n246090-6e2623c012c3-dirty: Thu Jun 24 13:59:44 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300509 1300509 has some extra text at the end that would indicate when the world is mismatched with the kernel: the last 2 numbers end up not equal and the prefix 13 vs. 14 would indicate crossing a major version. (Kernel newer, world older can be valid/supported.) > and repeating the previous attempt to build devel/llvm10 with no other > intentional changes.=20 >=20 >> Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got >> #define __FreeBSD_version 1400000 back on Jan-22. >>=20 >> Running newer worlds on older kernels is not supported. >> Generally folks to not track the KBI changes vs. the >> consequences of not having the right KBI. This makes >> interpreting results difficult even when it appears to >> work. There can be mixes like NFS not working but other >> things working. There could be corruptions but such >> may not be likely. Do you have what you consider >> sufficient backups it case things get messed up? (That >> might be the status of being okay with starting over >> if something really bad happens.) >>=20 > No backups, but I'm not averse to starting from scratch on > this particular machine. >=20 > As it happens, the poudriere session ended much as before: >=20 > FAILED: = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o=20 > /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS = -D__STDC_LIMIT_MACROS -Ilib/Target/AArch64 = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64 = -Iinclude -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include = -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default = -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fvisibility=3Dhidden -fno-exceptions -std=3Dc++14 = -MD -MT = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o -MF = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o.d -o = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector.cpp > In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector.cpp:312: > lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:41: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > = ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > = ^ > 4 errors generated. > [ 25% 1396/5364] This still had junk:false in /etc/malloc.conf ? So, if it is a kernel problem, it is an old one and likely also in releng/13 and stable/13. Beyond other things that I've listed, there is also that you have an unusual context in that you use GENERIC-MMCCAM. So I'm going to suggest using an official kernel build as built by the ci.freebsd.org systems, one that is not GENERIC-MMCCAM. In: = https://artifact.ci.freebsd.org/snapshot/main/66aec14a5391bda1e9a20f5e4381= 626797c3e0fb/arm64/aarch64/ there is: kernel.txz and, if you want the debug information to match: kernel-dbg.txz These are compressed tar archives. Possibly after first uncompressing, a command of the form: # tar -xpf NAME -C / will overwrite what you now have installed. (Make any desired copies first.) Then you can reboot and use the kernel. The debug info ends up places like: # ls -Tld /usr/lib/debug/boot/*/ drwxr-xr-x 2 root wheel 647 May 27 12:39:52 2021 = /usr/lib/debug/boot/kernel.old/ drwxr-xr-x 2 root wheel 647 Jun 24 14:14:08 2021 = /usr/lib/debug/boot/kernel/ drwxr-xr-x 2 root wheel 2 Apr 8 22:40:04 2021 = /usr/lib/debug/boot/modules/ So appropriate copies from there may be involved. (I do this sort of https://artifact.ci.freebsd.org/snapshot/. . . thing to approximately bisect without spending time on doing builds and if a problem reproduces that means my personal builds are not at fault.) > Not sure what to try next. I gather that no RPi4B is available to move the media to? (Having more RAM but being able to force much of it to be ignored can be handy as a test environment for this kind of context.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jun 25 17:32:38 2021 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 2EECB11E645F for ; Fri, 25 Jun 2021 17:32: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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBPGG0Zrfz4r52 for ; Fri, 25 Jun 2021 17:32:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 EF76F725B for ; Fri, 25 Jun 2021 17:32:37 +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 15PHWbJX035931 for ; Fri, 25 Jun 2021 17:32:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15PHWbkq035930 for toolchain@FreeBSD.org; Fri, 25 Jun 2021 17:32:37 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Fri, 25 Jun 2021 17:32:38 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13+ mfc-stable12+ mfc-stable11+ 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 --- Comment #9 from commit-hook@FreeBSD.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D1ed4655d9d5aab333eb5a89fafc208031= 5a0af79 commit 1ed4655d9d5aab333eb5a89fafc2080315a0af79 Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-25 17:30:41 +0000 Fix clang assertion while building recent www/chromium Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): [clang] Don't assert in EmitAggregateCopy on trivial_abi types Fixes PR42961. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D97872 PR: 256721, 255570 Reported by: jbeich (cherry picked from commit e7e517981a6591c79fb49cd8810361b0f3ad5983) contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jun 25 17:33:40 2021 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 05F4411E65CC for ; Fri, 25 Jun 2021 17:33:41 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBPHS5mxkz4rTD for ; Fri, 25 Jun 2021 17:33:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 2BC7F733B for ; Fri, 25 Jun 2021 17:33:40 +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 15PHXe8I036252 for ; Fri, 25 Jun 2021 17:33:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15PHXe3D036251 for toolchain@FreeBSD.org; Fri, 25 Jun 2021 17:33:40 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Fri, 25 Jun 2021 17:33:40 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13+ mfc-stable12+ mfc-stable11+ 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 --- Comment #10 from commit-hook@FreeBSD.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D858dc467c63c1be107808bcef91985914= 16ac71c commit 858dc467c63c1be107808bcef9198591416ac71c Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-25 17:31:22 +0000 Fix clang assertion while building recent www/chromium Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): [clang] Don't assert in EmitAggregateCopy on trivial_abi types Fixes PR42961. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D97872 PR: 256721, 255570 Reported by: jbeich (cherry picked from commit e7e517981a6591c79fb49cd8810361b0f3ad5983) contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jun 25 17:34:42 2021 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 9378711E6BAC for ; Fri, 25 Jun 2021 17:34:42 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBPJf3dznz4rrn for ; Fri, 25 Jun 2021 17:34:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 65ED6764C for ; Fri, 25 Jun 2021 17:34:42 +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 15PHYgVp036515 for ; Fri, 25 Jun 2021 17:34:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15PHYgXo036514 for toolchain@FreeBSD.org; Fri, 25 Jun 2021 17:34:42 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Fri, 25 Jun 2021 17:34:42 +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: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable13+ mfc-stable12+ mfc-stable11+ 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 --- Comment #11 from commit-hook@FreeBSD.org --- A commit in branch stable/11 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D591bd6a9b85d233bbef5eeaae46454f59= 94bf42f commit 591bd6a9b85d233bbef5eeaae46454f5994bf42f Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-25 17:31:48 +0000 Fix clang assertion while building recent www/chromium Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): [clang] Don't assert in EmitAggregateCopy on trivial_abi types Fixes PR42961. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D97872 PR: 256721, 255570 Reported by: jbeich (cherry picked from commit e7e517981a6591c79fb49cd8810361b0f3ad5983) contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jun 26 02:12:40 2021 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 1849A11DB241 for ; Sat, 26 Jun 2021 02:12:40 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBcpJ04vzz4Tst for ; Sat, 26 Jun 2021 02:12:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 E051C166AB for ; Sat, 26 Jun 2021 02:12:39 +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 15Q2CdNp013129 for ; Sat, 26 Jun 2021 02:12:39 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15Q2CdBf013128 for toolchain@FreeBSD.org; Sat, 26 Jun 2021 02:12:39 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 256721] www/chromium: 91.0.4472.114 crashes during build on clang 11+ Date: Sat, 26 Jun 2021 02:12:40 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable13+ mfc-stable12+ mfc-stable11+ X-Bugzilla-Changed-Fields: assigned_to keywords bug_status cc resolution 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 List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256721 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|toolchain@FreeBSD.org |dim@FreeBSD.org Keywords|needs-qa |crash Status|In Progress |Closed CC| |toolchain@FreeBSD.org Resolution|--- |FIXED --- Comment #12 from Kubilay Kocak --- ^Triage:=20 - Closing, committed in main and merged. Re-open if there's additional chan= ges to come with details. - Assign to committer that resolved --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From nobody Sat Jun 26 02:52:32 2021 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 7543011E1A65 for ; Sat, 26 Jun 2021 02:52:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBdhT73z3z4dhm for ; Sat, 26 Jun 2021 02:52:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624675959; bh=M0xQ5tU1gniF4ZeQX0RBwcI2XScmRE5Jctt6P2OT0bA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jkOmpGHczIk7MGzOhkJvXcgFe9tM+8esSFceTU4kw31lr3RxXyl56pt9MZ2xpAKo0Dr7mZNNp7v2YK8jIaMDdS8RZDizMLSNYSo/RQnq90QoN0pqCydHkS62Rhxedft2f4ZLgrKJxJppU8JJsySOIFhCChZks3GnK5cM7ZwFeNuz7ADobRbgYCzGZWFdItQ+dCBHtuLGQn0NLRBDt4XmajKwhIGTG8/E1Xnk/L7OXeFH9t8f8ygsIzx94D/Y59Jcbchgbjve2UeSh56rfr1VCEdeoZb5EySPqOUIR7w2uL4B0oZlNBjMZMZF2ZdSyQMweq1wFfJ+BDjttzi4Mr0syw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624675959; bh=aKOrK5IdYJ4YZegyS/4Qo1oTOPmUgGDHWW4M4KnJH2F=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pnmA5o22WVH1CKCL57EYUgZDhx6mMfo7TchxA+veoNZ3sLPQvQDc65q1yIkhXeJj9fr8TglYLe4WWIYX+NXnBAr3AqDRuztOoQrsDSBtoj5/TCM76ycydGdb4IXwwibI4HzLvhnt1Yb4DGsWWIHwH6zUh+TUzuK2gkBa+KotpOX5hNQffy+weta/jAyR+Hr/mrH+JGiNG+ppsJXNNPIKdHZekKGmfZwY+hkdykETrmsbzR8QlCpyt4hUs7OFu77OsMWCVdILA5LNQ2ARvCdrsVM/Z5oRQZk+9Z5pdMn7bgsPBR3g6W79j6toh8+KmnTxDKYq9bFnZ8Om5KoYut+6Ag== X-YMail-OSG: y1Q1lb0VM1nF5aVbpgeDWMy70DEY9HA4vcA3Al5z.eHtYmH8MkuAg3aWCjUpG3B oskJ1ElF8dvEC2gtRldn_qzmoJiY5XR6UkG6XS4UHvl3pZGbl2HlTk.QfLCesqHL1AwbDioRdSIK jC1Cw2P4aWiBa_IW89G0PgEtPdZitsgHzecidzAYPZPcUjR2VXGrlsH0rYcCjqxpC3p18mUbqDux lILvogYptOZH2xIQ3jFcgBtnf69v8PoKnvxN8xcUGPbzggDPlZFr6287q1uZTZz9xLBJgR3PUVKN l9DvdtAUcHaNnkdYObkI0zhvraJrVJioLJ.Gtg3MLfN.R6MHlLRzbJn4pyNCwuauI_3jmdQ2nl1_ GF3chHT_eDfaio2h8zqjabU.1x8sJnapbVVuTt1o.v0D7Wc2lb1pItjczqUd6FDveyME9zAhYq_7 Yd2IbnJVL_CdexoLjs6u8XQ5QDpEJDzzK5qmo3Qg923gAVazs9lM6GmpdDFCME9IvmjLYUg48teT ahnAStbN9TZtr6wD1sxrPmFTpB.RuIL8JvffiUBVWOwEJgVMePGL6YKJDNQB3ob73tcAqURy1VD8 fEOIQrEubCPO4zzYA7f64EUkps3vhB.fjSgpsJqodK6k0zFyojSnjy8xvvUhxtg97ZGaFewUPknK BMctdPLOKatGb85D9ro2fN_f6GtFlMUhWG5QPXL4_SoEdyDYSZTO.knLCKM.101T_OBLUhSPUcPm 4ehRuZT_1jllpQTU.4KEfxPRJU05jMTmEIse0K5gwpczU8GJ0GacYi.Hu5VUqZDvD0ahrIU1jsr8 IxN25jWWXtdRzX4.CT59arC5UVLuI48Yq2jIADbLKGhsEYzB9MFj2bj3rI5qbyMRWWXroM6MpFOa u7nuuXbjBFHM8jjxCqLB9E.mTWuljU4uGh0llU2OsWeMRhY0sWk11T8wIz7GkYj5B6KqqU1TjUaG 2NbYm4zvOga2JGcbrhzbY4O_Y6rP3JDDO4GrZIevv8qvIVkjQupLFo62lrYQFT0JxSxOS8KPn6p2 bFPm92eQpdo9rIPj9G_IwGiCnLEyymRUxndif6OT9E.Kp6jpY6jiRxJDw6Et1gCsb1pqiBugc_A9 LSJn7287DIKJNmdm0KF2f1cdGxDQ_JM4VCgDkC1yRaBQoBE.N4aMfDk2au779ebjhqM6fi.oZz0N WDitv_dpFm6avzOgvOwjyv5y.f7y2.v5dhhiw8p993ZrIrt4Ua.T1b4ViVn977MDt1CCCzQQMfqS xwA0fjVg4bl3Qqz54BzZS9weTsQbgv89WC5.R7UedjzXxXTVuT9AK4tEl1pOqkP_WNMNvd9TwIi1 MCW3giAnxW9W_OD9_OEn3LxH8rVsHPkyDsqRIacS2vDPH1No9QiwrcPuGoDkaJJItMZVX9SFnk7H keyxNciJFL3jcAcu9JFE_jvEDebmbjtTfBIE7L92STwInjNAX4wc6JjpeftVBxHhvU30OdTuYLue eXKNJxa1fTCaYkA_qmIaCzJo.iPkiuKsEj2pp4papFLu_WYLam_fUD3Ir2hAyTEQPcAxXZVzV5kf fwolN7KQW4GmI2w.pUMwe_zt8Gh2kRJZSOsaGFu4opAscO6zNfNN6xOzivHerlajdUubQnFkmuyR LAhnD4Dz9V6ghC.54iYDUVUdSaN0q554PJbiiz0dT7La9Tz_KMHDZZOMwIhSm8bGNoHpXEF6jJag UK_W.iBut58DIukzy2NSNUFy_H3IZDr8Ktct6tl0EKx3fY2Uvxf3Wiuzv1731ErfWctf_BNC.ppL .1xrKFYQvALUyIn62bfpVOAvj_pjbQ3AwwotCGa6hsMmYx_D1WVKJU5SjlZuJqrt4w5jB_jMZkyC iViUEMrJi2KfBfKZP.gkyRdLAuxQrV_GXLpxCqdcPVaFnJ8g5CkDn3iELhYjelK.OFd8yk8i78fn hktcUKjE.dqtbaxfaIh6JGsMxuE515JxVKjPviiGzgZRWufVs10Q0W17fnCM61kO2JWQSd66Cs.i aU92GuAbH1DT507U9_vCuaY83ZL7H6PmJf7TLdF9KkzrpKbovCrGCIEPU17cnZGuGCvx4nKkEx5u EwY4JleLuZ.phSWx7flMnBKSlPiDdPPxUVtYwG_53vM_IeaFFsD0iBjfclNLnfMp4TiejVUw3qYa XoxHtn0CYz9N091pV7LZRIwQ2.oBenh92OOF7K0GnOWRu8p8u.CGzVGtZQUlX_JUhcbHEFU2cEgM 8X8q7Xixnvx8UQWbYKPpN.XOAIbB4TmX9ILHfzdYaECICe5tlGKVPZ9PNEwnJu6tapQDqqVPQAXa 5RnxH5tYFB07uzFECnHg4CAYTtsfREQHiJqg46QpW1tuN1oH.H61RAhNItT7Oh5y2vneocAovScP GxBfyk_ooZCG9p_jzyzjbmagcPXhZR9tqu1QAlMscGhcKdYewt1JjTwOLaYrdbTQv6YG6omnwIKY 8MrwJ6MQWR_BlduwW4GaYyszHZICigkocBT3pON5.SLrN4eSEVS_5QgSQkiFzTNkgBRKIeIVuWkh nLyDC3E_ZMypCIWryr85kN2t890.anQ30Nl5YGAqCWlWi92iZltxpXE_bySLi0Ct36wLHVK8kTKp MwC3E_C8uZLTH3ZU2LlR88KfgCwHcxxOAgHxO7.9hkBl_fuleLzly74jrfsonPajZcgRpqjqmSyV XHkY.pxXW.APguML09g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 02:52:39 +0000 Received: by kubenode505.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ad59790cb08a79b560463ebe1bc01d60; Sat, 26 Jun 2021 02:52:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: Date: Fri, 25 Jun 2021 19:52:32 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GBdhT73z3z4dhm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jkOmpGHc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-24, at 17:54, Mark Millard wrote: > On 2021-Jun-24, at 17:16, bob prohaska wrote: >=20 >> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote: >> [huge snip] >>>=20 >>> So: Even going back to June 9 may messed up nfs >>> use. (I've no clue what services you depend on >>> or in what contexts.) You might need to disable >>> nfs even trying to start at the next boot before >>> booting into such an older kernel. >>=20 >> No NFS involved. Right now the machine is running >> FreeBSD 13.0-CURRENT #5 main-c255664-g4d64c7243d26: Sat Jan 9 = 11:27:58 PST 2021 >> = bob@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCA= M arm64 >=20 > I'll note that the output of -apKU fpr uname: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #3 = stable/13-n246090-6e2623c012c3-dirty: Thu Jun 24 13:59:44 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300509 1300509 >=20 > has some extra text at the end that would indicate > when the world is mismatched with the kernel: the > last 2 numbers end up not equal and the prefix 13 > vs. 14 would indicate crossing a major version. > (Kernel newer, world older can be valid/supported.) >=20 >> and repeating the previous attempt to build devel/llvm10 with no = other >> intentional changes.=20 >>=20 >>> Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got >>> #define __FreeBSD_version 1400000 back on Jan-22. >>>=20 >>> Running newer worlds on older kernels is not supported. >>> Generally folks to not track the KBI changes vs. the >>> consequences of not having the right KBI. This makes >>> interpreting results difficult even when it appears to >>> work. There can be mixes like NFS not working but other >>> things working. There could be corruptions but such >>> may not be likely. Do you have what you consider >>> sufficient backups it case things get messed up? (That >>> might be the status of being okay with starting over >>> if something really bad happens.) >>>=20 >> No backups, but I'm not averse to starting from scratch on >> this particular machine. >>=20 >> As it happens, the poudriere session ended much as before: >>=20 >> FAILED: = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o=20 >> /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS = -D__STDC_LIMIT_MACROS -Ilib/Target/AArch64 = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64 = -Iinclude -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include = -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default = -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fvisibility=3Dhidden -fno-exceptions -std=3Dc++14 = -MD -MT = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o -MF = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o.d -o = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector.cpp >> In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector.cpp:312: >> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:41: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> = ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> = ^ >> 4 errors generated. >> [ 25% 1396/5364] >=20 > This still had junk:false in /etc/malloc.conf ? >=20 > So, if it is a kernel problem, it is an old one and > likely also in releng/13 and stable/13. >=20 > Beyond other things that I've listed, there is also > that you have an unusual context in that you use > GENERIC-MMCCAM. >=20 > So I'm going to suggest using an official kernel build > as built by the ci.freebsd.org systems, one that is not > GENERIC-MMCCAM. In: >=20 > = https://artifact.ci.freebsd.org/snapshot/main/66aec14a5391bda1e9a20f5e4381= 626797c3e0fb/arm64/aarch64/ >=20 > there is: >=20 > kernel.txz >=20 > and, if you want the debug information to match: >=20 > kernel-dbg.txz >=20 > These are compressed tar archives. Possibly after > first uncompressing, a command of the form: >=20 > # tar -xpf NAME -C / >=20 > will overwrite what you now have installed. (Make any > desired copies first.) Then you can reboot and use > the kernel. The debug info ends up places like: >=20 > # ls -Tld /usr/lib/debug/boot/*/ > drwxr-xr-x 2 root wheel 647 May 27 12:39:52 2021 = /usr/lib/debug/boot/kernel.old/ > drwxr-xr-x 2 root wheel 647 Jun 24 14:14:08 2021 = /usr/lib/debug/boot/kernel/ > drwxr-xr-x 2 root wheel 2 Apr 8 22:40:04 2021 = /usr/lib/debug/boot/modules/ >=20 > So appropriate copies from there may be involved. >=20 > (I do this sort of https://artifact.ci.freebsd.org/snapshot/. . . > thing to approximately bisect without spending time on doing > builds and if a problem reproduces that means my personal > builds are not at fault.) >=20 >> Not sure what to try next. >=20 > I gather that no RPi4B is available to move the media > to? (Having more RAM but being able to force much of > it to be ignored can be handy as a test environment > for this kind of context.) >=20 I have a RPi4B 8 GiByte with total_mem=3D1024 (MiBytes) in config.txt that is attempting a devel/llvm10 build in a poudriere jail. But the host FreeBSD has: # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n247562-66aec14a5391-dirty: Fri Jun 25 03:25:00 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400024 1400024 and the chroot that poudriere is using has releng/13 (patch -p2 based): # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n247562-66aec14a5391-dirty: Fri Jun 25 03:25:00 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400024 1300139 So it is not like your context in some ways. Another is: my typical USB3 SSD based file system, not spinning rust. It is UFS in this case. The swap/paging partition shows as (for example): # swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/Rock64swp2 3145728 56360 3089368 2% So: no warning about being mis-tuned vs. the 1 GiByte of used RAM. (I do not know about your context for this.) All the ports that devel/llvm10 needs are already in place for poudriere's use for this experiment. Another point is: # more /usr/local/etc/poudriere.d/options/devel_llvm10/options=20 # This file is auto-generated by 'make config'. # Options for llvm10-10.0.1_3 _OPTIONS_READ=3Dllvm10-10.0.1_3 _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB = LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=3DBE_AMDGPU OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB OPTIONS_FILE_SET+=3DLLD_LINK OPTIONS_FILE_SET+=3DOPENMP OPTIONS_FILE_UNSET+=3DPYCLANG OPTIONS_FILE_UNSET+=3DBE_FREEBSD OPTIONS_FILE_SET+=3DBE_NATIVE OPTIONS_FILE_UNSET+=3DBE_STANDARD (So I normally build less than BE_STANDARD or BE_FREEBSD would build.) We will see if this is enough common context to replicate the general type of build problem. (Your details very from one attempt to the next so an exact match need not be expected, even if if this does also fail.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jun 26 03:52:34 2021 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 7EEA611E6031; Sat, 26 Jun 2021 03:52:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBg1h1qfhz4mmW; Sat, 26 Jun 2021 03:52:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15Q3qYvx018950 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Jun 2021 20:52:35 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15Q3qYLV018949; Fri, 25 Jun 2021 20:52:34 -0700 (PDT) (envelope-from fbsd) Date: Fri, 25 Jun 2021 20:52:34 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210626035234.GA18893@www.zefox.net> References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> X-Rspamd-Queue-Id: 4GBg1h1qfhz4mmW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: [huge snip, hope the quotes are still correct] > > So I'm going to suggest using an official kernel build > > as built by the ci.freebsd.org systems, one that is not > > GENERIC-MMCCAM. In: > > World and kernel are updating now to -current as of yesterday. I'll replace GENERIC-MMCCAM with GENERIC for simplicity. > > > > I gather that no RPi4B is available to move the media > > to? (Having more RAM but being able to force much of > > it to be ignored can be handy as a test environment > > for this kind of context.) > > It's still patiently chewing away at www/chromium single-threaded. My mistake, but best to finish what's started.. Now that how to use the packages created is known they can be tested. > > So: no warning about being mis-tuned vs. the 1 GiByte of > used RAM. (I do not know about your context for this.) > My Pi3 does report too much swap. But I remain uncertain about the practical significance of the warning. I gather the issue is that a certain amount memory is set aside to "index", for lack of a better word, the data stored in swap. If there's too much swap relative to index, not all swap can be used. That seems not much different than running out of swap. > All the ports that devel/llvm10 needs are already in place > for poudriere's use for this experiment. > > Another point is: > > # more /usr/local/etc/poudriere.d/options/devel_llvm10/options > # This file is auto-generated by 'make config'. > # Options for llvm10-10.0.1_3 > _OPTIONS_READ=llvm10-10.0.1_3 > _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD > OPTIONS_FILE_SET+=BE_AMDGPU > OPTIONS_FILE_SET+=CLANG > OPTIONS_FILE_SET+=DOCS > OPTIONS_FILE_SET+=EXTRAS > OPTIONS_FILE_SET+=LIT > OPTIONS_FILE_SET+=LLD > OPTIONS_FILE_SET+=LLDB > OPTIONS_FILE_SET+=LLD_LINK > OPTIONS_FILE_SET+=OPENMP > OPTIONS_FILE_UNSET+=PYCLANG > OPTIONS_FILE_UNSET+=BE_FREEBSD > OPTIONS_FILE_SET+=BE_NATIVE > OPTIONS_FILE_UNSET+=BE_STANDARD > > (So I normally build less than BE_STANDARD or > BE_FREEBSD would build.) I'm my own worst enemy when it comes to customization. The less changed the better 8-) > We will see if this is enough common context to > replicate the general type of build problem. > (Your details very from one attempt to the next > so an exact match need not be expected, even if > if this does also fail.) > If you replicate the problem I'll be very pleased. And just slightly relieved. My suspcions still center around things I might have done to corrupt /usr/local/poudriere. That leaves me wondering how to proceed after world, kernel and ports are updated. Delete /usr/local/poudriere (which would toss the packages created so far), delete only the jail (not sure if that'll delete existing packages library) or something more selective that I don't know about? The Pi3B is purely experimental, but I'd rather not throw away usable progress given the extreme slowness of that progress. Thank you! bob prohaska From nobody Sat Jun 26 04:41:43 2021 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 D22735D2685 for ; Sat, 26 Jun 2021 04:41:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBh6S3M9Qz4swX for ; Sat, 26 Jun 2021 04:41:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624682510; bh=zOM4GCNir6DcKKaefpXSp3bQLbwQwCQ45U4F/8VdDSM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z1X3upYwTGtxCJUTMIedH0w0prAuNWaY3OFpThbVMAMxxg9m1PfQOVREb5DxyluunKS8QlO70Tsi1ULt1CObRi+jdk+jsGx+ygY8aiB9OqwFY9GJYZeN6+6J4gajrO/IgclID3N94WejOoiPkfc4zAYspPEnePGRM7yiIsX0ozHSjl2D1bTQBjplMYP9w2N80GKSP8IdlKO3YWB+tUf0Fd0LPPI3/2+AwsnwF3MwNct/TYv91Ze0aBDrCXIWOkJtL8/FZ4waAuRkZVepZKUtcl+sFV+I5VKWkQ4B8CUuNhmMBG3wUP5dpuWzAujhZyShmzYeYTfFMe5TqAsd7JzIHQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624682510; bh=1C5BoyOPwof2qi6Jju8NZuumgH6Q6V4AGypvz7iJgDD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EB40BeWX378gdxAYqxcXEYo2CIb2Cw3oYZ5yTQ/ftapJQyrinbCbPNrlArh7tiSKg//JQtuk8g2xzrZcdOVBBXHyhfQ89Q+XdYGUUamVdtLh820pgaz5Fm2SgAEfuzsbNkOczBAwDj8wNPMWNJ5FwfjeTs2njf36ni997o7vNPZ7y9fhT+TAFtAd9pXolg165dvE6Zw50lUS6K0rh1cE8TfhEhyeHlpz9Dbkb69I4PZLZi8EUiznjpLNWhvsp8tZNE5oYS+FTF7+fgev8bNZzo81dZfOhGOKF9acD4aOXYBvDllMgDhiWMKUsTAv6gG14qlX7g2q+yLTsSD2wAtvfg== X-YMail-OSG: 6xDBy98VM1kxP5pIfweMXjCnmBZwFug8mfgQ09Otr1tEhXm3XnHtTxHry6bdafW YKM.ykVncOKf.D6KqLY2N2xWdGaCp93Wrlx4anSV6djg.S3GgJ8YszTq0Cy7A.EgL6ymtHKSajWZ VzsZHIRrQ_ALPs4XEH9FEnOszaKRpMHM.NQl4q1Nqh.SxMIXp63y.RW2_9DTJgrBxWz8SFj4B3My nTPxPorFydXnVNTBO6gBV5o7k8YMYAvkGygCnXs9OP1QuS11POIpRCDbR6bFpcqKyty_Z423UPy9 tW1HJC7_8QywekO59lRgCeJqhvfyCU9k3QhaoR3qcTRqU4lO84ix7QQ90hrwLiBkMGq3Ep5PKgud 2x6EiWbDdL.YWeK7mb0IgHmg8cibIKVC.UFeQr1T6lwnGIO.Y.O8j6xLlFAPrFJtBM8ds_HbQb4C GZx885C21J9MzEe4nSQfHAfYttlf8ndpv8hV_f2zLj8CoYXSRwsFncP0EY6Gb7IotorhSoAPI4GX rk6CLHu.AxQHQw3wT5TDUEAuYRGeL9ZhvdR28H.SKLB6vgODRiKGJ3Q64VOF1T7EGxuqHvqCEeKf pCS_aINqGUoZfBiHlz0v7tQj4fhungxrCCbiouJ6llMMFRRLRiBDDJy8FpSEmO48WOtNQSyNOYaq e4Y7GJ7qWA4fIW3.66GIAcjJ7wVrYv3Sakqpe1bQSEwdPszaeRU75mIME6J9rAh4VIlsrnrzFk3R _PIUPpffBmobpMlzIyrAERdWVr1VYRgZwl6APPBJdXQH1Yna8K4yH2lS7SqTyasu7B8H2Mpip4UB 8h8W4dSqhXRyst0GuGsaEHq0rVRC6_5yZ7.cnIMyJUSRLdHPpGfTgSAx95aC7F74TP7b4yj9_4e1 hcaO5s.M1QYvWFS0tFtcfcAHKFwEO5.OPNHE0ZSxdYHrg9DEWtRQYPzTXemZkB1dKFy4IXDccQ6d mpcvrV2JJyU9hp1H7qd8wnyJdLLLp1aW20fmQZg1NvZ2rZlqYU_8AJFQ.6h6CpccHPPg8Voc53mg qxET5ytyjuNUzY_.osWLYmwW0RUpKuX0ABuTu_jpBRU9SaQLxTz1QaIiShgvflMkXMwKkhfEtCMQ 7TJrFOuIU.vKD6VnSyXyzVzvEliemm2sxNSJKKtxYzL3MP_aPOpCfUwRhkc8RBJQhfZqW5elzukQ Q7fF9TpcsOX583oAvYVB3ANHimPM2wtQoigCoKRnfWmeLYBvjPYNOzIRrLAV7HtaLBS5Hhtzz8j_ vmgKyB16XuRIk7KIk1ess1f31exB7ck1DjHSzBhL4QOMI7F92wUfwa_wBRC8Qk2MQ_sHQwSzcEjg YzN8sSPYJCTgctsTnWY9tq_TC9gqJVXntC2lbvN.iJXa3A1TAIX3jp3lj1UywPm2M3SjxtDhtEAj l0NPJyzt4iQUq0gpRDPH1FD6tU_TuStP_U2mbdGIs2pdmAOOYrVpOKjTnjnrcI.4uKZtWRXboWfA BoxFIlo9Jy1TdzyD3hNW1hoP2TJa7bduQWKjbaMnCt4S8EPxS8sVNPY0V0idu3daeh3mub7ODIXG yHeZEMr8LULR9aYUeS8nwRBUwN2x3RYfX8y9W5rGaqbLO_wO_r_.1ttsbL2qLfnpcZvKEuWQ9gEb GXJ3znsKG06GJ14M0EJNcXNVv41biAAXqp.L884Y.VFrpfKlpUUQV1_pjYQINJ4zbu6TMUMsTxyV eL76koqmBx.3kdLgTjomT5B9t9q7pTOtwCr_oKRu3tOq2c9twLbE2fTUHsXXE4gDx.ZJd4tHbOrt _lA3rzeAPb4TenTyajTUVk_jbJRCHdWBKNJuWc0VKJO0NdUwSJUOlRXGIpo60efRJCxxbJM94MXo JWahLo5oDfbPnH.mEJoYOtg9AuxzaiZQ3i.X6O4G0k4IAMLKqNvqHrn2BCP.xKmwDFJbZ8CN31Zl TsEvPnmCNzSrmmYeVLZBqDFJ2CZl3heTBVIzLDkDP4ZPTotMtzge5l_H9uUnBHHOr.aqV2prqQL5 b0BpJTytoffkMlJALbY.zP5no29pHrzbCDWYY31GtRii8pk_r3_7xgBRg9lHNBocpg4T0xvVoZ1d eYx0V011Hkx47pdtpUVQrGHS6aofma4mzizH4JXbvbRxA_NdBIL3mw0ILMmCOwsS1JisnBIYBc26 q8IhfWmjCgwbgu6x8QHIxiYMWM8TTkLk8mhx_2NC3hV.H2w7.I7PeM6.vCzBiXtpwClZTaUxrLxl rhn1m3znndfxCHMbwATj2Zwp.tOXG8cgr0ZcjxMR2BVX39mL2SH.jYgE2om4tcGzNxu5VMoRVhQN yLK6GH5YTO4g1w.k8XY3.vvdr6xIMOuHMlwZSmb5zk_5s942zNqGQ01ExkR2QK1cNxQC3nA8V7in 7T22OTNm1b3dvsMJgRS.GAexJZf9tLvMTfWu0Xx36_5Y1n3i0SdZ3UB.qAVurTGhxveIW1z4Ilr0 Zjgr1ERCiKf5CrxjWZFnJcwHYKxwtY3cAIJxlMFZjGfaFV8nThJ10tsfvvyuuCRtIzmjRszpRy8N DwlkYb0589IIzN6zY1eyibxyZPUYVUBn_CqT2pQIpYOTvF8h8MJXfkI5cpn3eG0tN5RgYr6I_MpH 1EU_P7VWbS4I.DIVGo4txQR7Ensivc._g3YciboqOkhX6k66EUSqNO_BYQp0.dMvUyw8czJ8fCm5 CZgCvOvas7HGexOthc34RI2UxTXAHkMBNz58uO.jHQJtIt1MABMgcNpACdkMnwFbF_eX3mEy3BE3 P9_yhTQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 04:41:50 +0000 Received: by kubenode530.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3951e44e14e145c77bc847ea7989affd; Sat, 26 Jun 2021 04:41:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210626035234.GA18893@www.zefox.net> Date: Fri, 25 Jun 2021 21:41:43 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GBh6S3M9Qz4swX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-25, at 20:52, bob prohaska wrote: > On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: > [huge snip, hope the quotes are still correct] >>> So I'm going to suggest using an official kernel build >>> as built by the ci.freebsd.org systems, one that is not >>> GENERIC-MMCCAM. In: >>>=20 >=20 > World and kernel are updating now to -current as of yesterday. > I'll replace GENERIC-MMCCAM with GENERIC for simplicity. I still strongly recommend doing some testing of official builds instead of your personal builds. That includes kernel and world, if possible. Until an official build shows the problem, you are not as likely to get the problem worked on. (And, so far, you have the only known context for getting the problem.) >>>=20 >>> I gather that no RPi4B is available to move the media >>> to? (Having more RAM but being able to force much of >>> it to be ignored can be handy as a test environment >>> for this kind of context.) >>>=20 >=20 > It's still patiently chewing away at www/chromium single-threaded. Note that system-clang just got updates for stable/11 stable/12 stable/13 and main for a defect that prevents building www/chromium with a clang that has assertions enabled (a form of debug build contribution): The branch main has been updated by dim: URL:=20 = https://cgit.FreeBSD.org/src/commit/?id=3De7e517981a6591c79fb49cd8810361b0= f3ad5983 commit e7e517981a6591c79fb49cd8810361b0f3ad5983 Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-21 18:48:37 +0000 Fix clang assertion while building recent www/chromium =20 Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): =20 [clang] Don't assert in EmitAggregateCopy on trivial_abi types =20 Fixes PR42961. =20 Reviewed By: rnk =20 Differential Revision:=20 https://reviews.llvm.org/D97872 =20 PR: 256721, 255570 Reported by: jbeich MFC after: 3 days --- contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp = b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp index 60ea1b2af037..f3ab91559d30 100644 --- a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp +++ b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp @@ -2056,7 +2056,7 @@ void CodeGenFunction::EmitAggregateCopy(LValue = Dest, LValue Src, QualType Ty, Record->hasTrivialCopyAssignment() || Record->hasTrivialMoveConstructor() || Record->hasTrivialMoveAssignment() || - Record->isUnion()) && + Record->hasAttr() || Record->isUnion()) = && "Trying to aggregate-copy a type without a trivial = copy/move " "constructor or assignment operator"); // Ignore empty classes in C++. > My mistake, but best to finish what's started.. Now that how to > use the packages created is known they can be tested.=20 >=20 >>=20 >> So: no warning about being mis-tuned vs. the 1 GiByte of >> used RAM. (I do not know about your context for this.) >>=20 >=20 > My Pi3 does report too much swap. But I remain uncertain about > the practical significance of the warning. I gather the issue > is that a certain amount memory is set aside to "index", for > lack of a better word, the data stored in swap. If there's too > much swap relative to index, not all swap can be used. That > seems not much different than running out of swap.=20 You are having problems that are hard to issolate and are also effectively asserting this warning does not indicate an issue that is contributing. If it were me, I'd be trying to find out if the failure can be reproduced when the FreeBSD test involved classifies that no warning is appropriate. >> All the ports that devel/llvm10 needs are already in place >> for poudriere's use for this experiment. I should have mentioned that I have not added any junk:??? controls. And my building in a releng/13 context means that 0xA5A5A5A5u would not be happening on allocation. Stronger: the build context uses my typical forced MALLOC_PRODUCTION style of build. >> Another point is: >>=20 >> # more /usr/local/etc/poudriere.d/options/devel_llvm10/options=20 >> # This file is auto-generated by 'make config'. >> # Options for llvm10-10.0.1_3 >> _OPTIONS_READ=3Dllvm10-10.0.1_3 >> _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS LIT LLD = LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD >> OPTIONS_FILE_SET+=3DBE_AMDGPU >> OPTIONS_FILE_SET+=3DCLANG >> OPTIONS_FILE_SET+=3DDOCS >> OPTIONS_FILE_SET+=3DEXTRAS >> OPTIONS_FILE_SET+=3DLIT >> OPTIONS_FILE_SET+=3DLLD >> OPTIONS_FILE_SET+=3DLLDB >> OPTIONS_FILE_SET+=3DLLD_LINK >> OPTIONS_FILE_SET+=3DOPENMP >> OPTIONS_FILE_UNSET+=3DPYCLANG >> OPTIONS_FILE_UNSET+=3DBE_FREEBSD >> OPTIONS_FILE_SET+=3DBE_NATIVE >> OPTIONS_FILE_UNSET+=3DBE_STANDARD >>=20 >> (So I normally build less than BE_STANDARD or >> BE_FREEBSD would build.) >=20 > I'm my own worst enemy when it comes to customization. > The less changed the better 8-) Unless it avoids a problem? (I do it to avoid wasted time.) I'm not claiming it would avoid the problem, but it is one of the things that could be tried to see what happens. >> We will see if this is enough common context to >> replicate the general type of build problem. >> (Your details very from one attempt to the next >> so an exact match need not be expected, even if >> if this does also fail.) >>=20 >=20 > If you replicate the problem I'll be very pleased. > And just slightly relieved. >=20 > My suspcions still center around things I might have=20 > done to corrupt /usr/local/poudriere. Poudriere is not involved in initializing memory for llvm-tblgen's internal memory use. It could be that jails more generally have a problem, not just poudriere ones. But that would be a FreeBSD issue, not a poudriere one. > That leaves > me wondering how to proceed after world, kernel and ports > are updated. Delete /usr/local/poudriere (which would toss > the packages created so far), delete only the jail (not > sure if that'll delete existing packages library) or=20 > something more selective that I don't know about?=20 I see no likely gain from going down this path. Blaming poudriere for lack of memory initialization in llvm-tblgen makes no sense to me at all: poudriere is not involved in that memory allocation or what the bytes are set to before llvm-tblgen get the address of the memory. > The Pi3B is purely experimental, but I'd rather not throw=20 > away usable progress given the extreme slowness of that > progress.=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jun 26 05:14:53 2021 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 D369F5D7D97 for ; Sat, 26 Jun 2021 05:14:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBhrf3hc5z3GFV for ; Sat, 26 Jun 2021 05:14:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624684496; bh=/sWq9jUNSkIdBCzlGLZLIHkjK9SF85hlRgN0xvTJDdE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EytnGMjhqK7u3pFpRZSp3uU+R8ovlkdxX/Vd3nNs67Dz+Lmion5U+YsiVvcMblCMcJLE9G3Cmly9Chytk6WooDMGnfV+6W8ZnOj+mSZ5RbG0sgV5ZQUIkCWgKdI8kkqf2Cb01bKtj3it/Pui7Iwt67AddFVCHK1r/3GlyugFxCUgr98ilXe+2cwBO/+5XBw7k1elIC4tNwyd9132vle6VvxLVbCWMVdjY2jkddef+TTDIY6SdtiPF9P71h3kuoBpAcLKY40FLN1rXaA2T8NThmfuB/SjxD2WakCi6B7NgZDVhV07dYnGfnmzh+PZ+PsYccyCIfO1tQj1GwuuOzCBsA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624684496; bh=M06iD2QHuqZvfFCTEt/gjojb/fYvQ0uhuq9dIrOyNsJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cMvUkHEua4i/+UFWVh9KEOsEggrcQWlzMNIZhFZLClbV2x98rlCDUN86avK2G3r4mPtyEQ/mHkydY35D1aKjewriub84bLz6vj4w1Bck5PPDXf3nGTSeBXd0kGnWUMC8Fd899ZvUL9x6HhRvMNTLQNGlERoIuZ3ufSkBnRurEQ0S3PXJ1q78fsL8U1oXI1kiAHAPXB56DKHPowEJyGCUqyaY3Gykv+2jUEphuPZ71662212/US7Tz/uYxexX54AzzCu43PZFakXmxeDS+FpyFbBGEvpB7Qj+egD2kn1Bv+8pRNOqVmRIWXhQ4I7jpGnOQmPY0k7n3077XwNb4gW+BA== X-YMail-OSG: DhvsCyQVM1m882LFhwh27.dULc9mvVFPt8eKLVihFzwZlpR2DNqVr0ZZfd.LYwY TtdJdj0ymlpey9cR8s__ShSHumTifO0.S4vaItlAb7TfRxiyrla4LMLl3fqcMyAeTLwU98K3S88u PdlD.aOYcVcCoVIxL3HIF1EP.an8MBtZbUXeyyUHpTHuBZKUbGx3u_biv2VCEkupkSvy8XQASxXD CRR6n6lE8pOALNsllbq041ezZHtldxPnVWp.BJ_fE9_YtouEF4AoyJ9Gg0ggHU3t5.PcNxyqaoKg A3NnP1SquDVWnFXc9V0SLhkILogW6sjAaqYSHEEpJtPAteSPcEa8H1JNb02FZefDnsWHCSnGSE_2 iYhp1vP.XOwF7NZz7xgzaukSdRKFcoi0LlLEShslU3VfTnH5QfL3kNNXepc5c1yzqgeIZ3JHMjwS 7mQkKhzSES7k3R4U4s3Ow7oMX2eJThulu_ZZsWGH05shGtTwn9UGkrjQuGdR6i6tjicqLWShu13F Lm5C_g8ibEOqCzxevr_v4nyeMWwlClPtRLtqvIlJ.1L62B7cWyZhIlRhCcvkH59gZiCOs1BCA_02 6d6UM2pNcUCwphuoRkfQelwnEGtoMOFT9mJ4BM2f6s694HQpUhXGErpYWShJmnr06wDmz_sSyD7Z MdkLRpyvQ6yTjvIPTK95obkcjooR9hvIbbcOF7NGH_xrvdqojobNfl4ssUH3ql6WBsA.WPaeM256 aaQ3Ck62fzM2d2v3UXFo_UZUu7EG7MooJiFDZDSzhXsyL0fSk_FT5o9OVejN8vdz7KH7eNhc2gPD NqaW6I2ACNJ6UF183xKS97YncXQ7kdLxS23bFXY7_JJYe8coG4TE0TcwRey_crNMqxZQvKMdsyaZ lffRbXmelIBOyUTXoXKOtbkHFdYufy9hM.mUcMANoutbbIMwsj.M4sshr0g19gkZ4NfR_jTutxHu 5vWl0TInkkE5lN3hbhrP4NbKAznsculkZ2QF0hNQ6M9ucb5od6UtSSRykaEqCJx66S.D_vx4IWYv O23cmuyq5YkG7WsTr6oic_Or1ZIyIt8LKuowM0eaFXPnhJKw1VkknLtw9nLR.fTjI4bGNzKsZeCQ WPxHlLQczygBDjIzlWgBAJRX8FwDb2iNSgr.f5TLDr7TMQhZdnvoUsFZiRweiYXLzVC7KNKwfX9E jHMFdTy.Fpqd4ZMaYGy12Z8ecLQuj_st5x5Pn5tDyRv4VsUdbjcdXCCH8yBmpP.g5wRlc8TffpuE Q6yGKUKiDTXiDS2qyzg3Bd3dL.XNocBqfi020xXZRRS3Kvcdgp4EoREW50.Vz9M8aTxhbwjduaVp SiB3kKCOADiASbY_ViPpPbVvq5_82.NfX65X56dyJv2S3EsxQCpKDSXuKlO.zTovBmBYIL_fQ7A6 NaZEcBbo.5iwRLzNKt8_l2hoBrOFgrtBTVbQFY0L0BxLk0t3EqwW1Refh1teIbSw71toPfVcBXOJ 28YJkdba7AthiMwgru1_eaj3qrLv_a4Ztci6diJihntdMIGDXQHxX7AxI8eeuVymMzPesqc7lYOS _pXtTen8RaX6T8Ia6SdV5_6k9SCNKpAi2US7TAI8eylqp4qeavFfB1wF_dD_i9rA5VGMpT701JDj 98ptTs4H07AOAQdPVUeweq56E6Nsei947tBRZWeiysM.cBWdE6.CjYXzfXUTQKl8gX5F2kIQt6Gh BAIsGuBDGm6dCBat_yPc9BOGkxjf3_pk.RvvSGo.ZKRWDy1_bmB3air0GcksEhU0Ju6yayz6a8UT Licl_m6H6MBby6Nj33Iu.vvGNdAE5zN4q79a5CCRDP.X1NZgdryDFbWENKuYlhCgz8OQOOJFR1gl WB80ifLQrrFrwcRCc84fnKSbnnDWatOpqf9ygPi0M17UkvXtYsj1Q2VZz2sKtcZdK6B6hBKiEf50 yBsmYY_0DokOnLHGeV0owC3pPC9fCg21ug3yfG7j4JQfNqtgCPOD7Pu1XD2VB4J_K3rX5IrmTIg3 rtKFExF9ZZFu.BZsQfttQaujlP9FfDVyuEz5Vu56tZtv7.eps3PoIGoOecn1d3Y_oDqPkgVpGHBy eyp29tStsJ9tbp6hTSzwjYZTTcuw0ymOsFUseRhtqqT.5cqQ76kVTgcHHJQOeyzWlXTpjav4Zxvx gs.bhwChhs0hrs7yaQQ3Yo6QcK3mWZX5egxi84zpYE5s03c8zrfWYP_PipSwnc6ue2dgAGr7xhNa xb_qkSrixCbpoFuH7G2DzB0q88H2AH.Dohg7Jv7I4Vh2PvMMuhK29Uh.Pn6qxFiGSDwY.DQqggR. YNgxwabZY6Be69bRp6mM1ePSuAHKN_QqCBIC9DPEEaAQdDY72WA5otvCt9d4wyucPGcvWugV1UXT y7PmDpnEKTBxjlVvUKk3GnMiEIXlxiP6QdigzxO8.QD7eNZPAOLxJy.QIhr09_AIZ1Dc7.eG7GP. o.Cy5gLbKau.T5cK30X3GSlxTtT9h1EHdHw51MZD1S_7WPBJv06XRhkToe_3d03tygddGWcT5Gzy 1Ri31HawfEvUKJslbtTzduSoqbC5dN6__a70YB8AuN.2mOitXRQChXYRxj1Z0nkaFo06RxZgeg5J LWOKp0duSaS..RWh5ZeBZeVjvnRgRh06qTdR5SVqaM9ZLGX.CXwOHtudWqLHd0FWAXwEcsEF3E.U KiYt_vOrpqo6Yn1C_p9wdRf9IsGu7K0xHQT6ojDjylIqJzC5JvTerLlrIflp.zq52uLwxxw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 05:14:56 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7c66df145911c08e748c95207f4edd78; Sat, 26 Jun 2021 05:14:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210626035234.GA18893@www.zefox.net> Date: Fri, 25 Jun 2021 22:14:53 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GBhrf3hc5z3GFV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-25, at 20:52, bob prohaska wrote: > If you replicate the problem I'll be very pleased. > And just slightly relieved. No luck on the 1st try: [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ lib/Target/AArch64 -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s rc/lib/Target/AArch64/AArch64.td --write-if-changed -o = lib/Target/AArch64/AArch64GenGlobalISel.inc -d = lib/Target/AArch64/AArch64GenGlobalISel.inc.d . . . [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d Both finished just fine, indicating that the prior file generations were okay. I'll put the options to be like you are using and try again. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jun 26 21:53:51 2021 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 3892211F32BE for ; Sat, 26 Jun 2021 21:53:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GC71L0tg6z3p68 for ; Sat, 26 Jun 2021 21:53:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624744435; bh=A0/k+3ip0AMuSDMgvQwDKlvWNccib7SwxbEABhhLxh0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CxcYJXFj4CauNlSOwJAR8/+VIYPE3u9BTxXthsi8nursA2GBMZPOVjNmg4vW1mBRq1AaHQrxgt52uiC65+FaezPmT79Q1IWui47tOO8R19Jx1KT5J/ZQ6R7Y3MrrjrG+0eAeBIBrJIDrZvGe3VLZh8CRqz0VdQwnGBaRZ6RAwrZ2Dr0cGHw66+1mvI8OmliVw0aAN2x/cZ+XzXOBTFXsTWFGOHwg8IL5uAymuPLN44xlRdE5romIqoMmydBy5MVrYguP1WkQN0KupPql6Idp5aZ5Wa3DNaFHKIekp0+d1f7EMEo6jmvr32haOHx5BVrJrcxFJbjurBLpa1FksFqs+A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624744435; bh=L8V2dbyMGR2MuBqt18SPaFPSSoebD5XiPyWqE5Ie7BL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ULxkyHmnuMwCoqgnE6P98w6ZhjLl7aAtks8QHzkfBUC2xFvp4sSBhdLRaW6cEihceIx3F6mhiyBZTU1Cu3xE3Rt6IkKOu+RMn2P48zYVlVuNZGIziBdz/uf13n+xCkYGvCsZvWaKwZvnzEJsdL7G0nQcl2ssCAh+qaewhqY/ooOe2/o48zVKOxQes/u1qAZIG+WHpODwS5+XfktKyIdUf3cyRIBxBAUuUxnN2QLCtY3/9lxZyjJsEACkygg6/Fesl34xz0kMmf/BU/qb4V3c1hKezU3CPpGX6hz7PszkIPK8OLN09tfl2DGrVSOhL6G2Za2OdswM6CkWaO8cUQ7WDg== X-YMail-OSG: kwiD.M0VM1l4mGfy.Wb479BPN0fTwiJFHGAzOs0jafiutbcUeqy9gvmQ2Eji2kK sj6vQSbzw2hehI1HROQqCzDsBweDLmfxBmA90IzexRljxmUHZ0uXjQtf96sNYdv5OOCx9O0HKm5. CiD9OAed4RK_jDUDRFdwDD9zsce.cwEg6EvA2KZDQxUwBBwt6k3.a0vZYdIdXcaaqNViQ.sEs31h lN493fy1C1PKBWj9NbuOtpHPWHqMxeGsyqAAPz2jXpkzSJc3ZAXs4YVnCCAppd1EiAy2ghUiJQJQ nNX.8WigPUt6AYMW91_5mdNXi_BVpZF0Kd.c2dBJzxXedluBvUD4oZJJhHsfu1jmgk1glqjmrOZQ wmos5jwhKINWb4kt61_tvp6YjPNV9XGSS_hsmxd2uOse7RBY6mNE0EP9v2iJkmy4tW7aV5FKcNFV bgcJbkS4zkKLZhkeyOw_1JDMAh625IK6LheeQW5dc9ERHAr7K2syohLkZC8dX4S69zN4ukD8iSbb NIGWcNGNE1BKKOigUotksMd0sBWCy0UkMG5IlNzcW0mCQ2PArgAUwrYjOSTyFmrjymqB5MxclevX r.U2juepUFWUcuVl76Sbfglx7iPXLag8v4mASYS.fCJK6yl08rjx6eJ4xElgIzZWcZZdD1OQdcUC QgiybZota_m_AfNlF.9RXq8d4PVRMra90d4NQ6rIrzm2SXIoelDWgHwPeV8ArwXeaEjs.kftuL1H o4b7gAyr05vzjzTemO.j_1nAGAJe4zrKUG9Vb9kvh8hrmmBYjQA5LVhAFsBy6WBHs2YbkLEOuq4R mBY6ey.B_PgzyoKtYWdMvjQEvYYF49pIs3rKQj7QEDo2h2dAQso5qqwT4mPRn8ofQrz7o.Wuzek5 gFaYm2tTobQwRe7g6rkDbB6K994lLlBlK3t3K4XbJB8Ih2EUv6kb0KAzwpR2Oo.bDGhIghBhPP_H mZs_g7OZvYda9OdciCQ2TKIo08HBD6ZVjtxM_4jsiQSGprA_MptlBj0bkJS_zhouz9RNyyDR5xBj QWiMWXQRHGakNd662VbFtujZEsQDAXmY7eoN8rZTx0YtWKUgG.AEF29xPFxY2s0O3G2tXNnHaA6v 6_GqptAUGSU.1zIFDJTXQr2S71T2oZ079bgf46RJarwVRfAmcOQG.CDvMpXIhPDhpD.l7Hdx1YYc gw9X5VVb0G.7ev225KAxxNoQdBp3yEPf1t9dq3eONA.fpDTYt47EMHvdj5W97S7sGiGHGfub.15J i1kTFTrp8yZKVBvM2TIl5WfKAJU2n24y.O84EMoJnES7rBBUXC.39KFlTuqkciiU8VZG9LpRHuRm HRkybXQEOwh4ZBWQvHuTZT3sxThZ2Fo09gkgk3ohQPAoPlU_OhkylsTV4glC0p7CYws4F9g9LUIG YeWcEHFAqgW1e56PNq5ViFLxwgaMx5BCjAF2QjZxxQ8FS6rCKYkAb..a7PRb8jvGreYCqTsNPn9V ZwjeFBfTmbBSAm.HzTimllOWoTqFkLJfCdiOb_Mv.v1elxmqIAYkjtyJfNp5W2AEJKFVzGLnw6qD GP_KIoHRTZbASLn19kPDVumrASIsQUeDsd.1cXnEq9tm0SufVQ715KyLR5lOlJ6sGXfvjbrzU68w DKr3deVAcTC1XTvtz_J.oObraw8c.wZmpEw4MNwe0chUHVsEmzceukm8onUGTIE8f7LbbHJmj1I0 nzkULMEh12sWPqF55egaIjvZUl6O6BFXzYTq7Z_avoDpxfJwkd1x30HZIycwb9_u9OkC4evAYYYe USdPNMX5f342BHzotx3RGndXCO3GG89X9Cbpo..SDiJh7tD20J_1sP1KEE5n5sSnWE1F2vRXwRGS BxJO3uL5h.vkcS92oMZ82Fl45GpLSWIzTjw0z2OlSGW8Bw5s3aA9V1ti10fMjVevgH_BbEMpdEVJ 7mEY86XUdDC73iXb9rd20pl.VP5.6C5UAwIqtDC5hONpNDimoddYuro3vKHkG1uLPh4hPxgKyiAy qe6xIqwsvk_UN8mfnVRpsf3Jk4KJYUlnrOEJdLJokcSq8THEdK3sIKzlvDCyM3FVwGXlBuqSmjJV b.dzcQXf4rjN8G_1WAbGvxhFBceFeToBoKxOOpAAZi9cHHC_ZTPwIp5TnkJaa8eGdC4Aa0T6maXh BHVNNMPvzWEWlLXRQCswhc9gn.PhrblVOkOA56I5zPqlGnSirv6ExU23Uujl8i2MUOCfBYqPnG7z sLfafMZ9lIpdV2Jg1y_HhcvLFpWlnl6np0.GiXkZnr.wDsXLM3US6ffD5KKQFau6uBWYXnR1vEDQ dWReFzDiohV0SUlCCxr94IvC_SENIzLm3jcw8C7_aAq1XU3QhImAX1fQDYqbZ2ya4YxEQx_zzRn_ 07d4xvZgj9LbPvb8eyRm2v0iTyxMPvAtystMLOTIt4oUzeBcR6pam0_lcWmR1U_ThapLKXEtLTD9 PC5edEa_j4IcGIauoGaQLn0uQjFxprYr_ntZkvXhv3tXFKKJ6yy6uw7QNTA4Hj8Z6dqgRqvsEkDU RvaNNx1W_.M_pgpEvOGo_GSWWtR4FWSLbhrVpe3GNm0ls9VC2Hh1Mi4UsTs0JVVL9i9LHNaFwReW UShhGcAgVpCoyTQRrRhv.wYBq5ywDtMVPYbjroctkuMVVZiXhm1st.lh0nFQiVIMeududKOjyxfe 9mIQoruHSWquLfA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 21:53:55 +0000 Received: by kubenode548.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6f34e8b5252cd6660c6c0bd80f0b7fff; Sat, 26 Jun 2021 21:53:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: Date: Sat, 26 Jun 2021 14:53:51 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <43513842-6FC0-4A89-8F0C-9EB2B328A5ED@yahoo.com> References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GC71L0tg6z3p68 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CxcYJXFj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.66.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-25, at 22:14, Mark Millard wrote: > On 2021-Jun-25, at 20:52, bob prohaska wrote: >=20 >> If you replicate the problem I'll be very pleased. >> And just slightly relieved. >=20 >=20 > No luck on the 1st try: >=20 > [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ > lib/Target/AArch64 -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s > rc/lib/Target/AArch64/AArch64.td --write-if-changed -o = lib/Target/AArch64/AArch64GenGlobalISel.inc -d = lib/Target/AArch64/AArch64GenGlobalISel.inc.d > . . . > [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >=20 > Both finished just fine, indicating that the prior file generations = were > okay. >=20 > I'll put the options to be like you are using and try again. No failure. In a faster context with RAM such that there is no reported use of swap in top, I've tried a host kernel that is non-debug and a host kernel that is debug in combinations with host worlds that are non-debug vs. debug in combination with systems for the jail that are non-debug releng/13 based, non-debug main based, and debug main based. So far none of that has failed. On the RPi4B with total_mem=3D1024 I've only had the non-debug main host kernel and world and a world for jail use that was nondebug. But I've tried with and without junk:true. No failures. For the RPi4B, I've now got a debug host kernel and world and a debug world for jail use. So, by default, junk:true . We will see if it gets a failure or not. It is likely the last of the reproduction attempts based on the information so far. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jun 26 22:29:48 2021 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 C29AD11F4E7F for ; Sat, 26 Jun 2021 22:29:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GC7ps5xM8z3rW4 for ; Sat, 26 Jun 2021 22:29:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624746596; bh=P92VLgGOPzitcTQRUfclvKyD3zn/SW2uPEyJI8/08Qg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G2qSSHa5xNnZwtHm7Am4AElBGWe78fAy3afRnSIfCP+qJzwUFLmjaxmOE+ezVvUcYJt1BiElv+avoZpnFBRGGqZb6va7h8Lkc5XO+WYNaGh74iND0vedodmFmdbke2pUoOMJxAyKg6u+aE0Q/Mx08cj3YhD+fmOyY78hBaEQqb3xFUHWy7vOK1vlqeXpj/C/KTBNX3bmSpP5raNKn1z5q5y0l2823FlOxH5y7dBwAYV5GQbiuxBwH8fAafte1MIPSdF1s8oc2B0c/grk8IJlaAd38OWxlebHogdy3XyLVErwrhlBPNrLmdu88Mb2ZSziPalOmruwB7PqwpV8fHwuLw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624746596; bh=glJ01fIak/MFmjb5odXXWqZQPQo6AqQ7ASY0Y1/NTdw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Jxbt7u2Ka/3TDLaeBtpN+i1HUDFgNIv54zaytUeX0SC19+KpS1jSZg6N4PBzm9TWQxkHfF0/+eacLqZLfW4RZ6NTRz4ktWWWO/1FAXCDhRLgPfwwv8oS3fNG1UxJjfQOB/hD6B8JXIEsyTBt6yCz+hsFLAEFyxLP9wKdRfsEYRatczg/QMiAMK3oFsokpsn8e/wgRZPes9ZUHTNIatZalJYp/c0vRA1RrKqbpsg4J1Gd8B8R7E0OXGjOzzzAVruo92Rc0Hf2Y28s6gF1Sa//rlpQa+RfhmPixHu3QRna3ae9kljLB3lTRT0ly+ppPNaNr0QCw+SXekJUVvKWbkOfzA== X-YMail-OSG: gswy46YVM1lxAGItx7y9BSkQa55n7nvQODU1KZcc8X78KzegRR8AYUqFBWsWBNz .rHDyzolMGLKvYT5XG2PQpONLLyaO709hcaTIksvqaX9_DRNFkSO05yi_FCBGvE74uLTBaFcoC7i gsGvIPprNOJQuxFO11SkOZoGZA9idU9Z1LeC.JhL7IhOQPWlLsiBLhYcHOC13h_p8aT4di7gKcog lH8M2HXYVHDARjxxjwjPjfWddQA3PTry0kPTD9PoVos_4US0y8kEqvU_enx5Gz.6lOqzUMhKRKa. .Hq5TZyOfF2WYf.HmhVRljG9_zdU8SQSTluCnJk4HhzUcPh_OhUIBysk18Un.Q7XO2djTirXT5H_ m53Q3TXLvRNAteLQrJfY5IqngpaCAhLQiGd9adKnCRymRaMCACqSYQrnQ9dHWd9evAlnauSpUwNB H83yMHvyDZGqFR.Xt9VS5ig64KI22qO12AjOJ6T9CwfnHIelX84YvHjamf0Er.uBQ9rHplYPLxxA kyEHxBiKOPdMs7GT6MqjizyXjbCxDs36LEllSO1AvjzHO83_7KRQYFvA.MmWMLE.mIefGnQIi61j g1.R.PX96Ki4AJjTZaE0_wISJsgjIiWf0.4cdP.bpziVqVvSSM3L9PvCvWT0VQRxk.ZaSE5GIsTL guRVAR6aUoqm0oikfHfnQ4J04ux2zj.HBihZKvb1g9DzHkAt34nWWDHH0dSTg5t8Kd70FNw836gz BGvHRlRGNFZXKsInW7PFoXZelzhAQ4W2Mc54maCXpJy8rVxM5ALq0c8POcuipzdGS9OzTG4ksRDS .9AhABj0oN4NPUX3zH6XekIXWjt7SyOcE_E1fVmuu6.NTJF7XHoD8hj5lVWhBVB5Vv.9SUx4Jxri Lqw9S5ka0PAKkf3R4J8._94drZJLWwDK1s7nsG3fa_oEAz0OEibHU3U63Wt_nEZGiepd6ydZJ996 0XXlcU0qfNWYRoMja3u0pTj2LHwsrMdXD_m_QMcSVTrd5yNdpusxG6Z7ShlFOWm3wVPxhuGhR7cD nnyxJ8pzyLZ8Fwrd7.94WJNPTA1ZXDHDAPZXsef51PLl_n33uiiaQelPUXzscwgl4ETgaKnfgj_c K3GHO_OaD_20r3WijKWR1UDabKWtmv4L9cq6zmxE6AdgsA69_cL5cym3m6i3kadaK72yreFyanYi dqScGN91_CX0b7iAMrHxNH.x3Oo1bJ10g.ToNIcUSxrjTtJ7CEBviu5zF4zeOCoZFKhG6cAZb17t 2tN0ngF8FpcC9ggHCzvQN0vRjP7mbN5xVTKOjYiPmdB8NwvibRYo_ncYWgP.TMNcKSskDR_2bBQ1 pN9vrGrhgNHdRX.CJrdhaDyuj_j2qjSUI0Qa.Knuf7IfqdgdCYRs6J94.XX1go983NRJfscMYLrL QPZdiwk_u6TfTwCavZnRaO4RL9BKgGC_6irH9_4fsS0DaaIzC9B0ys7pPV3nHTPeo7Wp7oD9FhLd JiDKrmqe6p1dkoGbiIZzIGBFre2okgOsfDai0G0S0wjiKqPNW_7OXD2uXIWVN7BzxxpOoamiCRgH pY.44UhsJTFu5paR9PD2K6vA28X9AI833PYD8AOoSKqptv_O14FlcA44t2k7eFqlsdCv1nhbSvhB A7sjWn9X2Eo5ZhhKo5zYD0CfCi_AGt_p8.5C3AKTljG20nEzd2k9ISCT5RejEhRobeQuH2ACyXsi JHLLd92CRWXNlubEHGbxVM213EMNsJ6HhoBftGhtHGQAXNYCTe2BY4dhN3PxcvSEaOvKuJGsjnvL cUS.ccK9LSL48y5RvvnNofTMGJPxDzsp1iE4FZLk23_vzHuBRP6ehANsiI9m4SN5ep6dGA4cUcP8 UszaB_i9_s.sI2BD_YGnZt4nCcUixiwghIjLtkArxhPoC9SedD5pcjNmJQ0IQa3CQw3mjP17mhu. gTT808a0aprg9.cMMYMDqsDzV95bqllaHGIZT1uJDjKgKVXNEVfJAH49gmsnE0hFn3u4Jr4KC3Xb U.mCANcW9opdLX0_cj4J1mk1lK9mg4w.K86H1PXC1pxHk9G1N7mH41QkQ_iiQNBbyn.36t29V0Gy 6QMyjGbsuGAjiUxuN7JJY17bjsvHXIblOt5pi0UX.qldL_Qt711tsXE5jNVBb8N7pVYW8Cg24jfk OPb.p6wZrtaChBZy2.iPMhl3k_SQsBjxv5O9gT9EaB55QmkJX7U2JwlYOi29j1lPEGorYOpGEzEs X.m9zGX6MPYf6t9BO6MPGJy53xsKJ7tXdar9qpjqkQEn2pn9e.Sz9DJe5hG1X2L.5TlSbDOzJ2pO 1EgIVyPQDZXGI3c.Vw5UBO8Wp4971xXfBABmXSc_biSGq2Kogi9AgK5soN.FD9CRwc1TFT5Sv4Rj vHksCrur1PlaslX6j2n3Prb9VQY2jLyhmDBgoE91VmhFs8ZyqHTULrYsFNSaWAupamumWiQAqbSq ovVHVrV4BaqTprfJHvhFuOCcNThWjI70d99HWm4cyNhK7HJS_Vyo8Oux3u1c5ueAiJVyAEE4B8_Z sNl4Vx8yvOowAOHdG1enh85mOFLvCK31Mw3ZLdJgWc7.gjPYbiY8NTNGCv6PSNadOqjQ6JNZSqi2 PAxIUMEr9owGOt8m7NoyJeU9HndMvHz2cicBGXsha898mKbV1eaWlKOgS5ZCxIbEDz39nNmetEuk 0ccFY2wxO4U5.Ce1wJf0dWp0c56xhb_DE_H39sQIvFHEC3dcDLzFecyhRpox5YLhlvPXcnw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 22:29:56 +0000 Received: by kubenode545.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 256c0dabaa95b9b68ef21eaa35fc96c8; Sat, 26 Jun 2021 22:29:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <43513842-6FC0-4A89-8F0C-9EB2B328A5ED@yahoo.com> Date: Sat, 26 Jun 2021 15:29:48 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <9CFE71E2-23C3-4072-A8AD-74EDB339A146@yahoo.com> References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> <43513842-6FC0-4A89-8F0C-9EB2B328A5ED@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GC7ps5xM8z3rW4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=G2qSSHa5; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.66.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [freebsd-arm+owner at FreeBSD.org sent a notice of rejection of the original of the below because, according to it, I was not a subscriber to freebsd-arm. So this is a resend after (re-)subscribing. We will see if it is again rejected.] On 2021-Jun-25, at 22:14, Mark Millard wrote: > On 2021-Jun-25, at 20:52, bob prohaska wrote: >=20 >> If you replicate the problem I'll be very pleased. >> And just slightly relieved. >=20 >=20 > No luck on the 1st try: >=20 > [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ > lib/Target/AArch64 -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s > rc/lib/Target/AArch64/AArch64.td --write-if-changed -o = lib/Target/AArch64/AArch64GenGlobalISel.inc -d = lib/Target/AArch64/AArch64GenGlobalISel.inc.d > . . . > [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >=20 > Both finished just fine, indicating that the prior file generations = were > okay. >=20 > I'll put the options to be like you are using and try again. No failure. In a faster context with RAM such that there is no reported use of swap in top, I've tried a host kernel that is non-debug and a host kernel that is debug in combinations with host worlds that are non-debug vs. debug in combination with systems for the jail that are non-debug releng/13 based, non-debug main based, and debug main based. So far none of that has failed. On the RPi4B with total_mem=3D1024 I've only had the non-debug main host kernel and world and a world for jail use that was nondebug. But I've tried with and without junk:true. No failures. For the RPi4B, I've now got a debug host kernel and world and a debug world for jail use. So, by default, junk:true . We will see if it gets a failure or not. It is likely the last of the reproduction attempts based on the information so far. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 27 05:12:24 2021 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 916CD11D7CB4 for ; Sun, 27 Jun 2021 05:12:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GCJlQ1HHJz3Bxf for ; Sun, 27 Jun 2021 05:12:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624770752; bh=qO7qiP2+0vunWw0ePYtbOQjw4XHywnJ8FPAqYBXuf6w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sAR4kN6F9uqRkrIZhJdfIr4V/YKm5yjONI98CLsMH5OnXUsBRjWsapVteImOudLQuRZeZsEpM860oQRpgZri41jRXQpXZTj0wwItpzQlX7u/VHtd+pOxJKwoG+GtfFwAhhBjOWCsQjWWLi7W2yawPG/it86ALvknyQ/4hmwx8dTcEz9ij4nNZyV5AW7gDEvWkuGCfEd7puw9eaAlaK2mK9hLmSm91+pvpV0N1aVYHz1Eg/CKMSqrB/vdW6KMWd/rHhga2b4pZvbgBIBrBW6KALAyexLWcbVk17SfgEg4bK/a/rQFFMwbgYAPEQtbqJJqAzCAzjjtJMnjSBnwC2a06w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624770752; bh=31zuIi7h78UZTvj5Mkep014IuXafyZfn18i1rqkUbtm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mW4EeKSwNTaomII1CoC043YveIVHni62T+Us+R/UoD7xBSJxRm0b8Vf9mNmSPVUxTtQ12GI/CyqzH2+D2ioXF6VGLHx01NbpX5r1xqFkv5k7mljzExXgFD9D09++ZVkY43kOrJLPVtwjGBe8SRsPG/wg3QAl+eXBwMzTdA5+7iBdgDPgW/DFY0x7o5p1wZFfKXD86JPPDfllrXJGT2dHqbq0MZnTI6D8seQlLVkHRB2+CzQMv9HpVMTWic5OA0D+YkdJIfGocu+ceia7BFf++RPoZQkgdY2LiDcV/4yofsoBh5FmeumsJtBxEERJcghfONZaXxzfdaRusudC9feh+Q== X-YMail-OSG: hk7En7QVM1loHvVfShGXYp0A2lPK9LAfOSKimrsCPcfqT1LXznNunqtFHTQncdO WNK5k363fkwnXgFrp4mj4xdCFdIGAqwUK6tuuTE61He0ViWKIGd5tN4sxyPhIp05Hd2YwRzBdv4t 4nhVpeHvv0YUARH6qRimLsAAj_rXoKv63CpuQFdjtHRAPAV9EOx0hyyeV7yppqLgqwj8m24AEFzF VIViKgbkpeTVJOdXNKG1239zUHGyaRDENtUpyygNQqNZUreoaYcAsguq_GGSS2mONfG4hEkZ.vNl iv._lr8ZePiKYHXNCjlF.c0GsVAum2p9hnHempJRNk6C_omqp.w3uzCboT.gMgQmIDwLQCjk6rIT 24WNAXqsU_MrynLXEhr0Mgjt.mWhi2ADlPnx04sL_bfAJ2tgnruF7AejYE9cZCIieSkk.DVpaqoH Gudy3T7yTfkL_a_yi70eTDuyF6sZ8ehsJzr2bAujopeK4pkJC1lxG110Qlei9KTnxddDhW3RzWNq puQhFzTnutkZk_hnXnLGntp4DOxaq.7j7adf_7SXRTMulna0nV_uVFbDMhPFXBzVU0YDksEGCRDn aML9QOverNts5en89sX.UrM96jf.kDqHWF9eHrClxK.Rm4ftflSY3YXZks0ayJwP43ZdS9sgDRDa b3Nv9VZX4ljhK.UnW0FBgSkkSeWxduXxyoPNWSHRfz_8yd.HHRmheRyf3TgT98RoOwHhL4z.YJ_1 AA7TSYP9YtBcIKq_aMavtyNd_YLw5QPAOfqbkFhAWQo3Tm_9JDF19PPBh5awl1CvfSp9GgRZ1qEZ IFfGxvbtSXHFgyxFRgelqTQtbskp6JSwNcBOzB3D9fW3bUBL1LFeJpvMgbfRMJZvZDVqtM9xW4mQ sF9ZLg6cYsRXXAk.rs9jvYQxdvDWG6FXD8qzs4lyk_PhwodatwfHUC39Jt0q11hDQKLnkXFw62wR OtHzYylTv5q0_93FOD5coCPrFiCu6oEqMxJHcO.Wb6Lpfc9olftDQp3.mDUkrqadBzTysjAc4Oh5 lF8peMcBq_VbeeniMVUgi3fjSjoA.H6LFWUsOWYzYmlw8Sw3C3xfY8sWZ7XXcyuEnIGifyrUyoLA 69l7upzGf8bLt.w0EjWanWVNq3RMv_sUs1LvJF6sQ2Dgh9I8PlVfmarRxAx9GA0HBnxlGCFOuZuH fLxyh72XdiqhQ8A6NuKQohsFG1E2gY2cew3NlG9eahRj_nMZ.qOIKj1cEbQE_TMFsVQP1C26s6hj nayKeeHyNrzjK21SMgp05ghhlQ4Mqj_k5k2mj.GEOvPwOv2svYuMIwjjYqyVQ8166G37SRKS2Jdf RpRea6YFh2WxwtI3ZxKX.ho57ZEsd6d9rUCNVf6WHrwZwjF395i1d7bi7sgphaoirx7noJcyLyVv r55GNrpjgyWRaxpuCEPSV4332l9_xOIeaPm90gvmvGy3Qckfbi4zXxBKeVWlEZG0jqJlgCQm_A_6 vmNszumnlo4YUQaxsD_FWDwxh8dqLkSExEp.HuMB8dHZujh7g_lmNASjHPyOnLjQ631Q6yFgEOnj dxI6dQXp9taKDyRkTKK9QrteJzd.tivdzr6jrffZuJaEpS_Ed_LxFgYe09EcM3xfYYwIqHbSNT_8 oh3J4MAgjmDqkNzJiYiMCxxWIgKO2wxG8QQYMQhylZUauOZP.2LKTvCdGyGOKyxTPj1k52k.Ro1G bCaQ45natTDgCslc4lkGENTIlE0qqNNKqHT9jJy17gt5emo7nTIFaxkAm2.3ouCh2ohLoewsX3Wp 5j9H_dCMc1Tp5.F9Ln3.WVNerhEhQNPHFtJErKLD3Sww.FUULgwuaZVZChSsvOkZx2KbdS1furqq 0F0wa7vY4uGL9MwhzNV8EwIHLOibvuYHrD51YPipeFCLLhne1Oqmig7Xx.xkJOtQ57yZOx8ih4B3 9dOzcg6z82dY_2Qvljq1Gd.RSl5l_wNOE3E9R2Y8RG9p0CY95gOAhJ7tJ3QNxQW5BzBUHSwf83ed XgfJXAe8WL4TEqihCye7IimhbqzSdtwU.LDDx1GswsrMuexuWTX7LlEuuA6tpPYLZonaCW677A11 3kO4G.1qaPY66jHL09OvsuNsS0iiNs_UGa040FSvneA7VWpVSlpf3Ry1GGgQnh298gfu3.8nJn3. U6ip9ciwUkAxbbqXtAtUinT8copdvNIHWO_d17HS.s_THVTsWqg4v1ocJ14gYc.ngazu1P3kv_Tz KOriH5r14_ujek234cEpBcQzzTYU6ByCXi4ySTvheyjF5u7HiAG1cn00NiVyFV5EPEBhZlWV3Xw3 fWpN5e5clg6w5.kUqbHc7nUd3q7GB3q17q8NUrNI_53Mq7WnUb.VPr57gekDGeFWiN11sqFXTEKq c8rr2ShAnkNYne3gY1dXB1HirnAc00l8C5rTHF9XKgjrnGZAJXEbZQACXfJejk5PVCQL4qmpk.hp 0ubBhkN.w5QrSMQa6b6POxKXvnwm3GMBA6sts0UMARYgbyKNkgq3LZ.xnwrqkn.nm1Hb5tMHCpt3 W2HvbRbza5P3VHUaBYlyd4dN47mVZnoY3BRnGRSXVEPK3t6yGuTe9SFoUNeIXqtouOE.k9cWfsUU 2bl6SkEc4DDdCZR2C1UdqretO5CesHVN8C0zZWlCqtH0E5lkOpxrirZ19dz.umhuoAOqHtQ1TXOS OJSCIq7_f0KvI9HZNpmXFw6zn14TN6QyXG7nWM0MT2CIei7j7iERhhHUAGuFlRKeXt8LKuKxAiK7 CHgaeSpVdhF8uOQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 27 Jun 2021 05:12:32 +0000 Received: by kubenode570.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f0a0baccae6c4d683aea96a1b14770c8; Sun, 27 Jun 2021 05:12:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <9CFE71E2-23C3-4072-A8AD-74EDB339A146@yahoo.com> Date: Sat, 26 Jun 2021 22:12:24 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> <43513842-6FC0-4A89-8F0C-9EB2B328A5ED@yahoo.com> <9CFE71E2-23C3-4072-A8AD-74EDB339A146@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GCJlQ1HHJz3Bxf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sAR4kN6F; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-26, at 15:29, Mark Millard wrote: >=20 > [freebsd-arm+owner at FreeBSD.org sent a notice of rejection > of the original of the below because, according to it, I was > not a subscriber to freebsd-arm. So this is a resend after > (re-)subscribing. We will see if it is again rejected.] >=20 > On 2021-Jun-25, at 22:14, Mark Millard wrote: >=20 >> On 2021-Jun-25, at 20:52, bob prohaska wrote: >>=20 >>> If you replicate the problem I'll be very pleased. >>> And just slightly relieved. >>=20 >>=20 >> No luck on the 1st try: >>=20 >> [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ >> lib/Target/AArch64 -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s >> rc/lib/Target/AArch64/AArch64.td --write-if-changed -o = lib/Target/AArch64/AArch64GenGlobalISel.inc -d = lib/Target/AArch64/AArch64GenGlobalISel.inc.d >> . . . >> [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >>=20 >> Both finished just fine, indicating that the prior file generations = were >> okay. >>=20 >> I'll put the options to be like you are using and try again. >=20 > No failure. >=20 > In a faster context with RAM such that there is no reported > use of swap in top, I've tried a host kernel that is non-debug > and a host kernel that is debug in combinations with host > worlds that are non-debug vs. debug in combination with systems > for the jail that are non-debug releng/13 based, non-debug > main based, and debug main based. >=20 > So far none of that has failed. >=20 > On the RPi4B with total_mem=3D1024 I've only had the non-debug > main host kernel and world and a world for jail use that was > nondebug. But I've tried with and without junk:true. >=20 > No failures. >=20 > For the RPi4B, I've now got a debug host kernel and world > and a debug world for jail use. So, by default, junk:true . >=20 > We will see if it gets a failure or not. >=20 > It is likely the last of the reproduction attempts based on > the information so far. No failure. I do not plan on exploring swap/paging space sizes that produce notices about being mistuned. I do not plan on exploring use of spinning rust or powered hubs. Or using USB2 for the SSD. (Use of some vintage of RPi3B would require use of a powered hub, so I'll not be trying that either.) Not having replicated the problem, I'm not trying some official build from expanding the likes of artifacts.ci.freebsd.org materials. RECOMMENDATION: Since you have a failing context, I recommend that you do the test of using expanded materials from artifacts.ci.freebsd.org (so: use an official build) with a swap space size that does not produce the warning: See of the problem goes away vs. repeats with such an "official" context. Either your problem will be solved or you will at least be able to report information about the behavior of official build materials in a context not reporting a mistuning. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 27 21:00:19 2021 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 238FB11E6878 for ; Sun, 27 Jun 2021 21:00:20 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GCjmz6RJnz4sdc for ; Sun, 27 Jun 2021 21:00:19 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 B9D3F18BC8 for ; Sun, 27 Jun 2021 21:00: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 15RL0Jvu041991 for ; Sun, 27 Jun 2021 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15RL0JjT041990 for toolchain@FreeBSD.org; Sun, 27 Jun 2021 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202106272100.15RL0JjT041990@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, 27 Jun 2021 21:00:19 +0000 List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16248276193.c79feDFAc.41516" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16248276193.c79feDFAc.41516 Date: Sun, 27 Jun 2021 21:00:19 +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 | 234232 | clang Assertion failed when building the port dev Open | 245179 | lld: wrong/misleading "SHF_MERGE section size mus Open | 247665 | emulators/rpcs3: clang 10 crashes during build 3 problems total for which you should take action. --16248276193.c79feDFAc.41516--