Date: Fri, 27 Oct 2017 16:06:21 -0700 From: Mark Millard <markmi@dsl-only.net> To: =?utf-8?Q?Eddy_Petri=C8=99or?= <eddy.petrisor@gmail.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? Message-ID: <6BB7719D-6228-467E-ACA6-F849D290F9C4@dsl-only.net> In-Reply-To: <CAK0XTWd%2BkbOL38LKTgTXARmbJDc=obsR9T5ONSc9btkiz4CVsw@mail.gmail.com> References: <CAK0XTWczya8vg_sQZPqz-ZyYZRMq1v6p%2Bjs90S%2BjaDHxo2=1gA@mail.gmail.com> <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> <CAK0XTWd%2BkbOL38LKTgTXARmbJDc=obsR9T5ONSc9btkiz4CVsw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Oct-27, at 3:10 PM, Eddy Petri=C8=99or <eddy.petrisor at =
gmail.com> wrote:
> 2017-10-27 11:19 GMT+03:00 Mark Millard <markmi at dsl-only.net>:
>> On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or <eddy.petrisor at =
gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6BB7719D-6228-467E-ACA6-F849D290F9C4>