From owner-freebsd-arm@freebsd.org Wed Dec 30 01:29:07 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 45A3F4D12AF for ; Wed, 30 Dec 2020 01:29:07 +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 4D5DG94hT0z3vkt for ; Wed, 30 Dec 2020 01:29:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609291740; bh=UIveWhyYn8FDed596/D0JFQHuIPaV1MGvnCNhidn5rT=; h=Subject:From:Date:To:From:Subject; b=RA6Yhnsw/1gBLIhtTaasM1SaknDvga2cHAy0E4M+QV9iSYZzFR7Ao5nGKLmx8EtnZeeCl11fAhl1jNGEQMep+SlcpbYj+yeoFQIkm6PBjYTivGK4x2vys2Lp/Kpyw7Aonaiw85nGQDBWjAMR71JVVZU2mhNwHCYbeCARURuVrxpU8gZsDFuRdEDdU8RKiy0Rg6tgmmzHjnM0q1gE3q1O1WfXm/YrDg5u3vdPVtXI6JxVHh37JoxlH4ZBZUUMZ94+C+J4iM5BAnJsghvpBu5wSfZir8xiN7Qu6SsZuESKhMEjKLPFJc9gRDNL/BSGFPomABDxCh0T/t2HlEozGazl1Q== X-YMail-OSG: BpGc29EVM1nfL1LpcDOWT9vqK7zrcLfbyc9UHsUA4fCx90JczJ1GF.jQ4XxpFx4 PgDX4gehPH2Ci0Gmxkga7AqKhVFJk1KxGCywlINFxXHU0_dICl5YDgL1dFlQbpTmDhxtCBbM.g97 phxA8.9EpPc9pgZJQkAm5FwP4VK9MUu.HUAtT_sJxD4aE787LLBgW6RR789sqLXc3Q3TWfi74_zT LfLesp53_lcUY6I.OlCwpGsdAa83nJF6oeVrrrjKfFk7xQFZwcg7sLkpI1qD5Kf3X.4fl2BPY8lA DeTaWw.YgxIGwXFw_4G9W9r7MRkTihoW4wAu7IZP4AClD3luFj8Km5PdbTIyMElzryMKDYZrErf4 6L2ff6IS8mfUhMvgh6MoFe90ze.1b9eFkJZ1nH24HC2OQq6.HAks8LTNkyquHonloFbVXgj0fnZp mIFDTfVg8.l3W_8zDLC6JRrEq.mk0H98HXd9YYfc2gwskkqabwTdIRj3rQ6d0sR7les0e07go31V mS1tVjs6UAO4QyXMJYp_FJ_AG7wv7.SaWteByyEe8qF0EKjTqjRofDnz9mT5hpgJj4TZuyV6YtxC Q22SDem2tktGtDFLvJYrspFDp5wNtubFtzkbPwEqJ1s4Q9J_bT2mqNlZQ3ZFGqHt4IYZbEXaLjZh hYLDliLz4ZL4G_3K_FmUj.nQQ0m40bYBYy_y762Et.OS_KB5yqpaEkni..Ps.y.wBT4vCPXqjdfx Uf1RtKDK8CAZchh9s92wJi7hikW9c6mrCTAo6eYe7uoaISkyowbSktRhJ59OA7qDEPOPbRh9GFiq .w2dffXty4TfE2eMy9hibBdpfXx88A7nNVD.J6_8fhsjCX2stBHyQbAv5.s4C0Ubwo2pz5laXIKL wnDUiawnc51J81J20UXkJbwFMDiKeRGA9hMIHCxZ77JfrA2kvu.jssccUsQrAuQGe2ZYjmLX7eCl LfxDDXRejV3tfIV5tp_Lx7m03SJSsWuSR9.qmh3xMHbxCudwi.eBXtQVhF0BkRa4E4O8R8S5uWwJ HuTTekkN.wGfHuEUETQXrlHaZ3ZGpcGSQ_uECTD2oyUJfAwmt8iadrd.1.0eFG6L32SJ8oGRQnhz NzXO6oqF14.YbCrKaBLoP37Sfric2uXFyfx8KKYCmxR1N9CceMKscIuhI82HTOOAao00oixlFEHB 4arNsmnz6e.biU3yGHtpnXV9E2PlTnwFJ9zdRiUBXr0YW7XoAu25d354cnFMF1GkyRb0uzbIQepd DfeDXxSK_BxQ5aUcRops4XCqdD4ZaF.pYLRr1iEMO8_3g18JW0fjYuuLqTBACRBVTttw0q7bHs4n V1zMTmXacZp7pC65M9CGYKBYfSpKGA.8x48KEzpzr3Ka3JWF2t_QjalonpRG2z4Ha8Ykanft1OUc g.lhYNbRWoLdJZIpZgypCPKr55hVD50ThrYSf60zZHvYFqLTPhmfjnpbiPCDUS.VjcoUCoBGCKAq mdmmLRy3Jm5ogELyu3afu4E5i5dlXrwVXN2BBtppiiWsmsbx3D0.wJNvTohgLaCaYZXdT4CW0XMA xKhmQDjYQOpOF8zIhkQcfTq02FA0M5.f_Pq.R7LrYRggf7fvzfHnr0UHBqEHIUhnHOmgz8lCd6BP GXJoY4uNzuCmw9wDOFpy0kvWgHTl8artCxMon0A8ZLnkH23dBeR_bqT93yklSfbHBpe8aaHfs2bf DjzkQ3mZ86ZcNk79OpjkgQjVHveVMZN2u.mU4AkzXIcqv1h9QK1AVAOhs2ZNC9rXVrqFE2lBZt70 EfWaMj_l0DG7cP1V6IommYPDoaquGW_YTiwgLiuluYhfEsL_ovsoc75vk9KTlVVUl5C5onbfuP8E JEqXjsdC2Vb4Ao7WMLvwrnDW9Y2mTTwk.rK9oN2W.GlNm8cBQbAngJhm6IvLEz7jlu26TfRcN96z z9yn5_baXpfIM0g0DY.b_pLs2LmSSu_AeBdbhi33mgpUxEtLJsXY8o7uR.uOPLkzEVaJoNzW9cF0 OlUxQ8.d8MvlyE2uQhj3bK7yMRYyak3RQLi1sw4zROJ2TR6CY2MxE3QGtcDoQjaLg7Gm6er6kgsO V0TYmjCY2.VDn9UrXysaMVP_sagpsaWHWBcR9mQm9_jfi8RHVxeodJBcsyIOLL5z54y1apBOojfB XkMJRYeuKSWa5VhP8aUAjdSRyWs2GxjS4uSiCtsu3q4L.q2UKsXLaSbfDie5.rxWta8qagixFN0p 8nG.blLq1jGaaMnbSnXUjhGDYsrkIhMVr9oVfB7fr3JoGzVrHCnN71Pcht_k8ahRErQGvfRNArGP 8iaoFpemH_LPOkV6Y_ZOcx0iV7KtdaqSLQ1miIQvKL9TrB9ZABa8jg.RUG0.OPKz7CPMeS.eMzcb RrdZ3llvDOL8KVxN1Y25CUYMRMmXqz6MtB4cF.WiBpX3qJZA6JALHSkWHflXbEtW0lWuvxUn.XFi TIEp3I1P6_bN6KgYm3CyEf0dN2A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Dec 2020 01:29:00 +0000 Received: by smtp402.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ce98856f154ea40ef9c552c3fa6f1a1; Wed, 30 Dec 2020 01:28:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201229235701.GA49529@www.zefox.net> Date: Tue, 29 Dec 2020 17:28:55 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D5DG94hT0z3vkt X-Spamd-Bar: --- 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]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.32: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)[]; 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-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 01:29:07 -0000 On 2020-Dec-29, at 15:57, bob prohaska wrote: > On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: >> [clang.full built this time.] >>=20 >>=20 >> With the use of -O2 instead of -O , the bootstrap clang.full >> linked and the later activities in building the bootstrap >> clang worked as well. The build has also built the bootstrap >> lld and is off doing things that use the bootstrap clang >> and lld. >>=20 >> I've not checked if -O2 usage would be a sufficient >> change by itself. For one, various other aspects of my >> normal builds vs. yours could be different: I've not >> replicated your context in any detail. >=20 > Is adding CFLAGS=3DO2 to /etc/make.conf worth a try? The machine > is otherwise idle at the moment.=20 I'll deal with controlling -O2 use later in this note. It is a bit messy in my experience so it is not near a one word response. > As an aside, I've tried building stable/12 sources on a Pi3B running = -current. > It's already gotten past the point of failure and is now building = libraries. > Whatever is wrong, it's not present, or at least not visible, on = aarch64.=20 > Is there any hint where this bug (or feature) might reside? If you run armv7 FreeBSD on the RPi3B it will behave like the RPi2 v1.1 = does: it will fail. You must be running the aarch64 FreeBSD on the RPi3B for = what you state above to be true. The RPi2 v1.1 can not run the aarch64 = FreeBSD. So: it is not a bug. armv7 user processes are each limited to (virtual) = 2 GiBytes (or somewhat less) user-process-address-space (32 bit addressing, with a = bit reserved). aarch64 user processes are not each limited to a (virtual) 2 = GiByte user-process-address-space: the user-process-address-space bound is much = larger so the effective bound is based on other things. aarch64 still usually = ends up with a larger effective user-process size limit than 2 GiByte (depending = on RAM size and swap/paging space configuration, for example). What -O2 is doing is inlining functions and the like, cutting the amount of linking of functions and the like at ld time: -O2 make the linking less memory-size-needed intensive. Back to building vs. assigning CFLAGS . . . Directly assigning CFLAGS (CFLAGS=3D or CFLAGS+=3D style) can be = problematical, with that definition possibly overriding internal definitions by = preventing internal CFLAGS?=3D usage from picking up material or other such in = contexts=20 one is not trying to control (nested contexts). I have run into such = issues historically. Here we are trying to control something normally supplied internal to = the build infrastructure, only in places where that stable/12 = infrsuctcture's normal CFLAGS?=3D -O -pipe would have done the assignment. We do not want to be adjusting other contexts that do things with CFLAGS ( including, possibly, other uses of -O in nested contexts). We probably also do not want to analyze the whole build infrastructure looking for places to worry about inappropriate overriding and figuring out what to do for them. Such also applies to using, say, CFLAGS.clang+=3D that would add separate text to the command lines without disabling the CFLAGS?=3D = usage (for example). Then things get into order of conflicting options and which "wins" and if that is always an appropriate result. So the only simple technique that I know of is to change the actual file ( share/mk/sys.mk ) that has the above line. That limits itself to the correct context directly. Only the share/mk/sys.mk copy in the file = system needs to be changed: no need to have, say, a git branch of your own = (unless you want such). I've run into this before and have used my own share/mk/sys.mk variant as needed. I actually use CFLAGS.clang+=3D and the like for something = but would not use it for this -O2 vs. -O issue. If you still try your own CFLAGS assignment, include the -pipe as well: CFLAGS=3D -O2 -pipe Otherwise the -pipe will end up missing. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)