From owner-freebsd-arm@freebsd.org Wed Dec 30 03:54:50 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 D89EC4D3A56 for ; Wed, 30 Dec 2020 03:54:50 +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 4D5HVK5mT4z4YJQ for ; Wed, 30 Dec 2020 03:54:49 +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 0BU3smU0050733 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 19:54:48 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BU3smxa050732; Tue, 29 Dec 2020 19:54:48 -0800 (PST) (envelope-from fbsd) Date: Tue, 29 Dec 2020 19:54:47 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201230035447.GA50440@www.zefox.net> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D5HVK5mT4z4YJQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.08 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.989]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] 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 03:54:50 -0000 On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote: > > > 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.] > >> > >> > >> 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. > >> > >> 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. > > > > Is adding CFLAGS=O2 to /etc/make.conf worth a try? The machine > > is otherwise idle at the moment. > > 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. > > 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. > Yes, the success case ran aarch64 on the Pi3B. > 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). Doesn't that make it a bug specific to armv7? Perhaps not global, but a bug so far as users of ld would see it. > 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= or CFLAGS+= style) can be problematical, > with that definition possibly overriding internal definitions by preventing > internal CFLAGS?= usage from picking up material or other such in contexts > 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?= -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+= that would add > separate text to the command lines without disabling the CFLAGS?= 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). Looking at /usr/freebsd-src/share/mk/sys.mk I don't find a CFLAGS.clang line. There is a snippet containing .if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "mips" CFLAGS ?= -O -pipe .else CFLAGS ?= -O2 -pipe .endif Indeed, I don't see anything that distinguishes armv7 from arm64. Am I looking at the wrong file? /usr/freebsd-src is the stable/12 build directory, cloned by git. Or, is that the problem, that armv7 and arm64 are treated the same way? > > I've run into this before and have used my own share/mk/sys.mk variant > as needed. I actually use CFLAGS.clang+= 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= -O2 -pipe > > Otherwise the -pipe will end up missing. > Are you referring to /etc/make.conf? That seems preferable to tampering with makefiles. With my thanks (and apologies for dumb questions)! bob prohaska