From owner-freebsd-arm@freebsd.org Fri Oct 27 23:06:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B279DE52C47 for ; Fri, 27 Oct 2017 23:06:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-106.reflexion.net [208.70.210.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 724547E42E for ; Fri, 27 Oct 2017 23:06:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21654 invoked from network); 27 Oct 2017 23:06:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Oct 2017 23:06:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 27 Oct 2017 19:06:24 -0400 (EDT) Received: (qmail 19027 invoked from network); 27 Oct 2017 23:06:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Oct 2017 23:06:23 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 317FDEC8A28; Fri, 27 Oct 2017 16:06:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Fri, 27 Oct 2017 16:06:21 -0700 Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6BB7719D-6228-467E-ACA6-F849D290F9C4@dsl-only.net> References: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> To: =?utf-8?Q?Eddy_Petri=C8=99or?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 23:06:31 -0000 On 2017-Oct-27, at 3:10 PM, Eddy Petri=C8=99or wrote: > 2017-10-27 11:19 GMT+03:00 Mark Millard : >> On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or wrote: >>=20 >>> I am trying to make the FreeBSD code base build from a Linux host = and >>> found this bit which defines BUILD_TRIPLE in a way which to my >>> untrained eyes look like overengineering. >>>=20 >>> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || = ${CPUTYPE:M*soft*} =3D=3D "") >>> TARGET_ABI=3D -gnueabihf >>> .elif ${TARGET_ARCH:Marm*} >>> TARGET_ABI=3D -gnueabi >>> .else >>> TARGET_ABI=3D >>> .endif >>> VENDOR=3D unknown >>> OS_VERSION=3D freebsd12.0 >>=20 >> I'm using a context where armv[67]* would now >> likely be in use above, in fact the context is >> from an armv7 build, no longer armv6 . >=20 > I am kind of confused by this part since I expect the BUILD > architecture would not be that often and arm system. Maybe in my wish > to provide some context, I added too much and sabotaged my own > question :) I took your notes/questions/suggestions not as local workarounds based on your local context but as changes to FreeBSD materials themselves in order to more directly support bootstrapping and building from Linux in general. Looks like I got that wrong so most of my notes are not of much use to you. Sorry for the noise. >>> TARGET_TRIPLE?=3D >>> = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} >>> BUILD_TRIPLE?=3D >>> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>>=20 >>>=20 >>> To support a Linux host I made these changes that is using 'cc >>> -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if >>> it shouldn't be OK for building on a FreeBSD host >>=20 >> Using an arm FreeBSD head -r324743 context as an example. . . >>=20 >> For reference: >>=20 >> # grep BUILD_ARCH Makefile* >> Makefile.inc1:BUILD_ARCH!=3D uname -p >> Makefile.inc1:.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} >>=20 >>=20 >> # uname -ap >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 > [..] >> [After looking into the details my preliminary >> guess seemed to be correct: the only dependable >> uname output among -m -p -i was for -m for linux. >> The uname.c code used varies from distribution >> to distribution and that changed the other >> options' results.] >=20 > I am not that concerned about this aspect in the context of my > proposal, especially since NetBSD's build.sh takes better care of this > on the host side: > = https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316= b/build.sh#L486 >=20 >> Back to the armv7 FreeBSD head -r324743 context. . . >>=20 >> # cc -dumpmachine >> armv7-unknown-freebsd12.0-gnueabihf >>=20 >> Compare that to the results of: >>=20 >> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>=20 >> Note that on FreeBSD itself on that machine BUILD_ARCH >> would historically not have the "-gnueabihf" suffix for >> such a host. Would the build tolerate it? >=20 > Why would a FreeBSD host compiler report the triple with -gnueabi = suffix? > OOTH, if we're talking about using clang, the exact triple reported by > the actual toolchain would be used in the clang/llvm compilation to > define -DLLVM_HOST_TRIPLE with the exact value that makes sense for > the host triple, which seems the right choice anyway, at least to me. My example is what it does produce at the end: -gnueabihf Part of the reason is likely that FreeBSD allows building a soft-float based FreeBSD instead (still called armv7 ). hard-float based is just the default. The -dumpmachine output needs to indicate the distinction somehow. They choose to be explicit even in the default case (default from a FreeBSD point of view). This should apply to clang and to gcc for targeting FreeBSD. >> # cc --version >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) >> Target: armv7-unknown-freebsd12.0-gnueabihf >> Thread model: posix >> InstalledDir: /usr/bin >>=20 >> Note the "armv7" for what Linux might instead have >> something like "armv7l" for a little endian, hard-float >> context. Would this matter? Would the build tolerate a >> armv7l (or other such) in BUILD_ARCH? >=20 > My point exactly, gcc and clang are supposed to behave identically > from an interface PoV, so I expect the BUILD_TRIPLE gotten via > -dumpmachine to be identical between them. >=20 >>> +.if ${BUILD_OS} =3D=3D FreeBSD >>> BUILD_TRIPLE?=3D >>> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>> +.else >>> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine >>> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} >>> +.endif >>=20 >> Keeping the historical BUILD_ARCH content for FreeBSD >> hosts might be important. >=20 > I was only wondering about BUILD_TRIPLE in the context of llvm = building. >=20 >> But for non-FreeBSD hosts, such as a Linux distribution, >> might other mismatches with FreeBSD conventions >> matter? (See earlier above.) >=20 > If we're on a Linux host the BUILD_TRIPLE should be the one > approrpiate for the linux host, not the FreeBSD. > If your point is that I will have to take such things into account for > the cross building from Linux, I am aware of that, but that's not that > important now since I am still stuck in the bootstrap phase for the > cross compiler (linux host, freebsd target). >=20 >> Also: What of using alternative compilers (${CC} vs. >> cc in classic notations, may be ${HOST_CC} or some such >> here because multiple compilers can be involved)? Would >> "cc" always exist and be appropriate? >=20 > That's why I said "host 'cc -dumpmachine'". I didn't care much for now > for all sorts of checks or corrections such as using HOST_CC, I was > just curious if the idea of using the '-dumpmachine' output to define > the BUILD_TRIPLE. >=20 >> In fact on FreeBSD it is possible to buildworld >> buildkernel using a non-system compiler, such as >> via the devel/powerpc64-gcc port, even on a >> powerpc64 system. (This allows a modern build >> instead of what gcc 4.2.1 is limited to since >> lang does not sufficiently yet.) For that >> context: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine >> powerpc64-unknown-freebsd12.0 >=20 > yes, and the HOST_CC or whatever mechanism was chosen to select the > host toolchain would have to pick the desired cc. >=20 > But from what I can see here, the BUILD_TRIPLE would be correct for > FreeBSD if using -dumpmachine. >=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version >> powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for = powerpc64) 6.3.0 >=20 >> I'd expect that the historical BUILD_ARCH content >> for a FreeBSD host should be kept instead of ending >> up with things like "-gnueabihf" tacked on sometimes. >=20 > Are you saying that based on BUILD_TRIPLE there is some later > BUILD_ARCH definition? That sounds wrong. FreeBSD's original materials constructs BUILD_TRIPLE from BUILD_ARCH. That means that they agree, with BUILD_ARCH (from uname -p) leading the way. Your change no longer has this property: uname -p and cc -dumpmachine need not match (for the part of -dumpmachine output that may or may not be a match vs. the part that never matches). uname -p output did not have a stable definition across Linux distributions in my past experiments. uname -m might be a closer match by content to FreeBSD's uname -p. uname -m was stable in my little bit of experimentation. You might need a local workaround for BUILD_ARCH as well. Again: I misread the scope of the intended usage of the potential changes. So, I missed your interests. Mostly just ignore my original message. =3D=3D=3D Mark Millard markmi at dsl-only.net