Date: Thu, 16 Aug 2018 11:08:39 -0700 From: Mark Millard <marklmi@yahoo.com> To: Ed Maste <emaste@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org>, Dimitry Andric <dim@freebsd.org>, Bryan Drewery <bdrewery@FreeBSD.org> Subject: Re: Broken arm support in clang now? Message-ID: <70A9144F-EBD8-46F6-8E2F-98A630A897E4@yahoo.com> In-Reply-To: <FE00838E-6EC8-4923-A068-0C9566A22F97@yahoo.com> References: <CANCZdfpmDN-nAkViuEx-tKpPhOdRYX=xNu6s8E2o6F4xC2WPnA@mail.gmail.com> <1880880F-9D9D-47E0-A7A4-5369A3770F89@FreeBSD.org> <CANCZdfpF9ND_k2xvZrsDebsZ07p2RU0Lebp5GDtmxnjdXc=N-A@mail.gmail.com> <A5B46840-B508-4F40-9EFD-50D0439EBAC7@FreeBSD.org> <8B467E75-A6D3-41A5-8EA1-4DDFE0E14CC5@nexustechnology.com> <CANCZdfq4NmT6_W9MwSMC8r4fQfxW8fWyh1pOX5snnVLNEvew9A@mail.gmail.com> <230C1E7D-04DB-4E45-8A40-F6B2F5E557E9@yahoo.com> <CAPyFy2DW86vT2bJBpoznCkB6U8HTYFyYH29Sb=-aCBPd65a=Qg@mail.gmail.com> <86844298-1268-4F5E-A6CD-64CADC022FB9@yahoo.com> <CANCZdfpFr3vZYt9SS46wtutEdXR7e3QqS2WiFA2usrkrqAY%2B3w@mail.gmail.com> <FE00838E-6EC8-4923-A068-0C9566A22F97@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I found the ${LD} use in /usr/src/sys/conf/kmod.mk .]
On 2018-Aug-16, at 7:49 AM, Mark Millard <marklmi at yahoo.com> wrote:
> On 2018-Aug-16, at 7:16 AM, Warner Losh <imp at bsdimp.com> wrote:
>>=20
>> On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard <marklmiat yahoo.com> =
wrote:
>>> On 2018-Aug-16, at 6:38 AM, Ed Maste <emaste at freebsd.org> wrote:
>>>=20
>>>> On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
>>>> <freebsd-toolchain at freebsd.org> wrote:
>>>>>=20
>>>>> Is the link command itself available? (The =
.../sys/*/kernel.full.meta
>>>>> likely has it if it is still around.)
>>>>=20
>>>> I tried a tinderbox build right now and saw the lld warnings from
>>>> linking zfs.ko. It appears to be fallout from the change to build
>>>> clang and lld only once for tinderbox, because we're invoking ld =
from
>>>> the ${HOST_TARGET} path:
>>>>=20
>>>> =
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr=
/bin/ld
>>>> -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=3Dsha1=
>>>> -o zfs.ko.full zfs.kld
>>>> =
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr=
/bin/ld:
>>>> warning: lld uses extended branch encoding, no object with
>>>> architecture supporting feature detected.
>>>> =
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr=
/bin/ld:
>>>> warning: lld may use movt/movw, no object with architecture =
supporting
>>>> feature detected.
>>>=20
>>> So ld.lld is not a valid cross linker for some arm variants? A
>>> architecture specific bootstrap one is needed?
>>>=20
>>> Is this because armelf_fbsd is not specific enough to
>>> identify the accurate target emulation? Is it because
>>> the .o's are not sufficient for that identification?
>>>=20
>>> Note: I got the questions from reading the output in:
>>>=20
>>> # ld.lld=20
>>> ld.lld: error: no input files
>>> ld.lld: error: target emulation unknown: -m or at least one .o file =
required
>>>=20
>>> So it appears that -m and/or .o's are used to identify targets.
>>> I'm not clear on the criteria when both are present.
>>>=20
>>> (ld.lld does not take -target as an argument.)
>>>=20
>> lld uses instructions and features introduced in armv7 =
unconditionally to do its linking. The bug appears to be that clang =
invokes it unconditionally in some cases.
>=20
> Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based.
> Intersting.
>=20
> But I took Ed M.'s text to be based on the .meta file where
> he listed:
>=20
> =
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr=
/bin/ld -m armelf_fbsd -Bshareable -znotext -d -warn-common =
--build-id=3Dsha1 -o zfs.ko.full zfs.kld
>=20
> The implication would be that ld was then directly
> invoked instead of via cc (clang).
>=20
> Looking at a armv7 build I happen to have around:
>=20
> # more =
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-N=
ODBG/modules/usr/src/sys/modules/zfs/zfs.ko.full.meta
> # Meta data file =
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-N=
ODBG/modules/usr/src/sys/modules/zfs/zfs.ko.full.meta
> CMD ld -m aarch64elf -Bshareable -znotext -d -warn-common =
--build-id=3Dsha1 -o zfs.ko.full zfs.kld
> CWD =
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-N=
ODBG/modules/usr/src/sys/modules/zfs
> TARGET zfs.ko.full
> -- command output --
>=20
> It looks like ld was directly invoked instead of being
> done via a cc command for my amd64 -> armv7 cross build
> example.
/usr/src/sys/conf/kmod.mk (from -r337400 in my context)
does:
.if ${__KLD_SHARED} =3D=3D yes
${FULLPROG}: ${KMOD}.kld
${LD} -m ${LD_EMULATION} -Bshareable -znotext ${_LDFLAGS} \
-o ${.TARGET} ${KMOD}.kld
.if !defined(DEBUG_FLAGS)
${OBJCOPY} --strip-debug ${.TARGET}
.endif
.endif
So it is the ${LD} value and $PATH combination at the
time that is picking out to use the host-system's ld
command, not clang.
So this seems to be a FreeBSD build system problem when
the wrong ld is put to use for cross builds (where llvm's
lld can not be used but clang can be).
In powerpc land I've not seen this in my clang experiments
because my, for example,
src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host
is explicit about setting where to find binutils such as ld:
TO_TYPE=3Dpowerpc64
TOOLS_TO_TYPE=3D${TO_TYPE}
VERSION_CONTEXT=3D12.0
. . .
=
CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSI=
ON_CONTEXT}/bin/
.if ${.MAKE.LEVEL} =3D=3D 0
. . .
XLD=3D/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ld=
.export XLD
.endif
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70A9144F-EBD8-46F6-8E2F-98A630A897E4>