Re: Migrating from -current to stable/12 on RPI2B (ARMv7)

bob prohaska <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.