Date: Tue, 29 Dec 2020 19:54:47 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201230035447.GA50440@www.zefox.net> In-Reply-To: <D562F29B-7154-49DC-B1FC-1ACA20695897@yahoo.com> References: <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <B6A3C3C8-4AB9-43B5-A93F-8F2B6DE5E5E9@yahoo.com> <CB0E5ECD-CDDA-46A7-812B-744AF7645A78@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <DB6C87A3-19DC-4979-AC17-FD1261782803@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> <D562F29B-7154-49DC-B1FC-1ACA20695897@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote:
>
>
> On 2020-Dec-29, at 15:57, bob prohaska <fbsd at www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201230035447.GA50440>