From nobody Sat Feb 05 01:00:05 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7D0CC198D2B4 for ; Sat, 5 Feb 2022 01:00:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4JrDbQ3tfLz3lwt for ; Sat, 5 Feb 2022 01:00:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644022810; bh=w4nc2zA2cK5vMcRGf/z75nF8pJvvT9QxbKdDay9MVEA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i/55nxEkLkew1YLG5gTYDYMzZupTLcFsXsvg6bz9chcwhqlKkD7HFHgUBOuw7fdE80e8/yIH6paVKGJA/rMDfvk6eHT86si+1c5PCZ6L1X5HlupRYKJqUIF+NnT6ffNRhkgI29eZCLc2WbzGsHGZ05bCEUCcbpxEOGBJ29heBp0gzWN5ISoaoL+nlq1JvM1R5w3vcs0RTp9f5glaJB1U0Xw4xsyNpZyNx4QY7BWRlczjQOz3yzBIcSyhAOo+LsOyQjHtB9c4kSSnYEv48iA9UIzCbxkKT4u/jLw/nnahEHpd5nWZmUJDa6BX0JQ5gNVupKHC6IMkSCm60ZEtI9UVKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644022810; bh=bg8Nd6BvwMPMPFtjaqxP1RP7BcZxqjFAuHuIbojK2wH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Gus4iTrlclUmkHUU37KifJa1DN7r2c0LXz2J2gBbRq1T4nc6Z12YxU5J00gPQdX6gfE5+DmBllhpuRb2SZ/eGdYEugu0u5nuXhzIZWooWQ6XsnmiFu5FkeXHHwMuOkUx+b+XhvbuJh0AREXjiFhPCUnOwU6OR6xhG3XZV4A8r3V9Y9h23YDHtT0bRxKfrgeDL/PJDVvr8J5OwzXtUHOSQThSAH0+xQ80/HP+bfyzpfYAWHIuwPjMbzsx8mA0amuWmaA3uOElAE80bE3P56mQn/Noo0U0a0xGe43quYmWGqcqhUEd28506UYF5h/GBMrTmCF6trHD9evL6ev/U69WtA== X-YMail-OSG: .zpRz3sVM1mzDaA7MBPjiieObPKQoFmeiizPztE5M.f53sfaI2cF6Pekqzfeu6A 7UnBlbFwKYp0UE8KBdmLxr8B_C33PgO2MoiEcp7cfCNzOuxQcjKciLDKS.YKFGZ1dn5Ano.VWBaY KvClti.7urP4XgJmil96fFHkoicw8XXazlF_1wzaz6TX.qNAKFsUd7Lzs52U5ttn3LBo5Q8MnojD UFRK3dTuUYG_K9BccbRQ0FCsOHZaqO37UeVT6f_zXaRqvQ9oLhFTPy3QILDXxQhvHVrBaHavDhI3 0FOskrZAdNduPY.HxlevXsb9RHi7XPyXNENcGGmnzV6Bf1Vd4zo0WFZ7OIeh5hk2xCd8R0RZaKw1 sfUJNIPwY1iV__Ro9XS0OBeVZuzom8AOH9mILNeTYCHKLnBPAdedG3MpqYO6VmqqUETGghI9n1Hj yDRcHQVcfoaUtlzGjcQHrTDk6AhzMYFl.sZeWmBNeqUHdk22hiTVIHiCIDdnyIJpRMzspmyf75qv LCVGzU5b7zOr9YQ5K16QPYobe3qpOAgXNt7.PwnO2v09O7nwReuUyevNWyPSV0CkL7pkuP7Qaq3R JrgHw0y1G5wBdMzp4KCEib6pBsKY_trSLOKQZOs9v.M_fwesCCQFGJmHoj5rJ_kML47ssG4DLTq4 dTisvjIeRpK5A9XullR0zIw5qWfsDQFvkH8Af4qPBbkw5iBU1Li9yN5WBD9nur0HqvN_fWauhbVa rtFYtnv9sSjtlsm0W8_IYd5TW5ifh3Ypz.9RKMHG8ON1Ygb23Z3LCweMd23lCG66APl_Ktr46Non RTtbWlU23LgRAvgP7KX4uzUsta0FTfarZ2H_gbepgHcGgfTB933A5LVb951e3nn4S3p1.54ljYuP uTJQ__5st0PaK038g39JmTFIZ5ldrHjPEmqI2vqxjJU.LwGYGAsqq4KB944Kr4eT7e8fbCJBsLuL o0OviMvC0aAm1lYmK7GxYzN9KmveoS_ug2bLPLe7vH5H16.3uvRxNCRYQZ2T0v4mP_V20NBfFejB SbHOL48aXmvLTxlQBm2MKT89ALMhEyJYVjPc7Wwx7MzeK3WTtO_wn8vZI4sKf_RPzUagAh4irqzt EWuCkNrB5c_EH2POzaEFY3zjbeRIpRGhrE0IBT3tKkTsbuhBEehdwkC1AdLwfVb14249ZucB.IRW QzPTotXnKFeLeIV85Ymq1Hm4158pwGmPKG8U7ViGM1np8luavbW9yx.3mpScdtOgYecKpoZ6QXt. NvbmTIQfZ8cCt8W_EPfT.URUWDqGhHT_RhdrqiiVfNLq3mTF4_Oqq4_aRmjDAcc9JGzZJcSgvFcW EdXk6ZUDwKKKSnLUBUpRNagm9lGsZKzIHBGBjuvCYQw4sipGWY72yKp8Ry3d7QEjVr_9ilX5VLn4 cXsh4MC.QF0vBmaPcbFLtPtrsOKTdQ_MUXVHHO49sOB1RfRG3UNIYFfyyt_b2oxy.PZ0WxTz4V95 MkGkWQCvZ8ngH.KXX3c2Q5.OEQbnOaSr5MWk9gjvG4_O1jeXZ9BrKnPRHcP1QUFW_UM6j.q3UJsS .9I9RV5pSAMHCkzONdyGfzORc5dp4Jz2_H7YgWeDuAqo5_eWSqvCDZXvBLcELV5UmYtlMKDcN86P F.uj__flIkAUXyflodw3404FzU2Ubl5SdLTujulcvNxrHgAq63zCcQsXE1F3XJXoDFuQk2vmgdTF MgP65nOT.NUSX3ikfLdk1bjuIwhMntyDo8SxcpeVBJ0tes4LyPNEv45NgoqE6Vqh_G2hig3BxkL2 sJBDFGbJXOa4QBeEilDbsEpPiBAy9bGwczzB8a_hMfH3evBNEzS4Ah0GzY7W76DTe7rM0.TKChHV r8dPGlboEIJ26QoA0I.o9snC2G7M6lLp1c13UuAtP7zKOHX1.IAXppJ49MWKlE2dGTxpmE261Yy8 O77W8qVi7GMhHOQaQkyI4.9NqdXN0nL40C2ZXQrnL26r4Nbdnmh.SxxYYdUyNXfHyBNCElNmJjKI W9j.dLuN5J3owfEIym0Zsfm0HlLAOF.2f3zMrc2pDo6PVWX0urLaD0XLTr23WU8QK5aA3lvP1svu _hUwyrV9B.vjZ15oaoVPYGcPMIlP2JGBKvGVqdO0ZqzVmaatEZjq0SCswGgbehFMAwe84GwMIhdw uq3qokMQKnYhoOWwM0lm15SsCDUopiFnf7wCdrsL7brNvYv6p2GHLtgwWafib6nyO75QOcpdRoQY D04Z1jNrCPysiW7Xo_4ZE5geur_FGA8DKTqqbYe40IUufty7HveOuTnCEahdjY_6XPm7NFnTQsa6 gBQwkYt71b4gzWBlj X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 01:00:10 +0000 Received: by kubenode520.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 44d554cc74e436763e7ecba47c6b52c5; Sat, 05 Feb 2022 01:00:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: <20220205000800.GA85644@www.zefox.net> Date: Fri, 4 Feb 2022 17:00:05 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> References: <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrDbQ3tfLz3lwt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="i/55nxEk"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; 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)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Feb-4, at 16:08, bob prohaska wrote: > On Fri, Feb 04, 2022 at 02:44:01PM -0800, Mark Millard wrote: >> On 2022-Feb-4, at 13:44, bob prohaska wrote: >> >>> On Thu, Feb 03, 2022 at 02:05:38PM -0800, Mark Millard wrote: >>> [chroot setup snipped] >>>> >>>> It would be good to know what experiments produce relative to >>>> failures vs. successes: all one? the other? a mix? Part of the >>>> point here is to test builds from official FreeBSD build >>>> servers instead of personal builds. >>>> >>> >>> I placed the chroot directory under a regular (wheel group) login, >>> but otherwise followed the instructions successfully, I think. >>> Since all the installed files were owned by root, I used the >>> root login to work in the chroot. >>> >>> Five attempts to run the .sh/.cpp file produced all successful >>> results. >> >> Interesting. Currently it looks like your specific compiler build >> and the ASLR (Address Space Layout Randomization) somehow >> interact, leading to sometimes getting the SIGSEGV's. >> >> I have only reproduced the problem with the copy of your c++ >> -- but it stops reproducing in my environment when I disable >> the system's ASLR mode of operation. >> > > It sounds like I simply have a corrupted c++. Perhaps just > set the old version aside and copy from the chroot directory > to /usr/bin ? Granted, other things might be wrong as well. I'm not so sure. My expectation is that if you first do (presuming not already in place at the time): # sysctl kern.elf64.aslr.enable=0 and then to your buildworld buildkernel it will just work -- using your exising c++ compiler (system clang/clang++). Note: There may be a way to set a specific file like your your c++ to force ASLR to not be enabled for it when it runs. But I've not researched that (yet?). So far I've not had any example of failure with that setting in place. It seems very odd that such a setting would "uncorrupt" your clang/clang++ build (used under the name c++). I'm not aware of the compiler doing anything like the ntpd did, for which having ASLR enabled as a problem. For far as I can tell, the setting changes the detailed behavior of mmap calls (including implicit ones in library code and such). I've not found a way to look at the context just before the failure (without disturbing things enough via debugger activity that the failure does not happen). It is likely that I'll not manage to get such evidence that includes the failure. I worry that the failures seen with your c++ involves a kernel bug but I do not see a way to investigate that. >> You got later messages about the ASLR disabling experiments >> that I did. >> >>> Next I tried to use lldb. That produced the usual >>> preliminary output. However, on issuing the run command I got >>> >>> error: DupDescriptor-open failed: No such file or directory >>> >> >> That message happens when devfs has not been set up >> for the dev directory inside the chroot. In my >> instructions, before the chroot command, there was: >> >> # mount -tdevfs devfs ~/13S-chroot/dev >> >> that set up the dev that was in 13S-chroot/ . It >> does not survive reboots and needs to be done again >> after a reboot --from outside any chroot session. >> In my context, the following shows some checkable >> consequences of a correct, active devfs mount: >> >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/gpt/Rock64root 823229 194087 563283 26% / >> devfs 0 0 0 100% /dev >> >> # mount -t devfs devfs ~/13S-chroot/dev >> >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/gpt/Rock64root 823229 194087 563283 26% / >> devfs 0 0 0 100% /dev >> devfs 0 0 0 100% /root/13S-chroot/dev >> > When repeated with the instructions followed correctly lldb works, > the result is exit with status 0, success. Nothing to see here.... Good to know. Thanks. I expect that you can use: # sysctl kern.elf64.aslr.enable=0 to make progress (buildworld buildkernel). You might be lucky enough that after installing the update the problematical combination will not happen. Another option might be to use a copy of the compiler from the chroot area to replace the normal system's copies, possibly renaming the old ones first (various names), including deal with clang.debug as well. This presumes that the 2 stable/13 builds are sufficiently compatible for such a substitution to work. === Mark Millard marklmi at yahoo.com