Re: Broken arm support in clang now?
On 16 August 2018 at 10:49, Mark Millard wrote: > > Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based. > Intersting. Indeed; there are a couple of patches in review upstream to address the outstanding issues involved with using lld to link armv5/armv6. > The implication would be that ld was then directly > invoked instead of via cc (clang). Yes, the issue I encountered appears to be a bug in recent logic that shares a single clang and lld for multiple architectures in "make tinderbox." It's directly invoking a newly-built lld. The other issue observed with lld errors from linking arm or armv6 appears to be due to a failure to execute "make buildworld" or "make kernel-toolchain" before "make buildkernel." In this case the build invokes the host's system linker (ld). Previously on amd64 this was the GNU BFD ld, not a cross-linker, and this resulted in an error. Now that amd64's system ld is lld it's inherently a cross linker. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
[I found the ${LD} use in /usr/src/sys/conf/kmod.mk .]
On 2018-Aug-16, at 7:49 AM, Mark Millard wrote:
> On 2018-Aug-16, at 7:16 AM, Warner Losh wrote:
>>
>> On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard wrote:
>>> On 2018-Aug-16, at 6:38 AM, Ed Maste wrote:
>>>
On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
wrote:
>
> Is the link command itself available? (The .../sys/*/kernel.full.meta
> likely has it if it is still around.)
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:
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
-m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
-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.
>>>
>>> So ld.lld is not a valid cross linker for some arm variants? A
>>> architecture specific bootstrap one is needed?
>>>
>>> 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?
>>>
>>> Note: I got the questions from reading the output in:
>>>
>>> # ld.lld
>>> ld.lld: error: no input files
>>> ld.lld: error: target emulation unknown: -m or at least one .o file required
>>>
>>> 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.
>>>
>>> (ld.lld does not take -target as an argument.)
>>>
>> 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.
>
> Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based.
> Intersting.
>
> But I took Ed M.'s text to be based on the .meta file where
> he listed:
>
> /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
> -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1 -o
> zfs.ko.full zfs.kld
>
> The implication would be that ld was then directly
> invoked instead of via cc (clang).
>
> Looking at a armv7 build I happen to have around:
>
> # more
> /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/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-NODBG/modules/usr/src/sys/modules/zfs/zfs.ko.full.meta
> CMD ld -m aarch64elf -Bshareable -znotext -d -warn-common --build-id=sha1 -o
> zfs.ko.full zfs.kld
> CWD
> /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/modules/usr/src/sys/modules/zfs
> TARGET zfs.ko.full
> -- command output --
>
> 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} == 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=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
. . .
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/
.if ${.MAKE.LEVEL} == 0
. . .
XLD=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ld
.export XLD
.endif
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
> On 2018-Aug-16, at 7:16 AM, Warner Losh wrote:
>
> On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard wrote:
>> On 2018-Aug-16, at 6:38 AM, Ed Maste wrote:
>>
>> > On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
>> > wrote:
>> >>
>> >> Is the link command itself available? (The .../sys/*/kernel.full.meta
>> >> likely has it if it is still around.)
>> >
>> > 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:
>> >
>> > /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
>> > -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
>> > -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.
>>
>> So ld.lld is not a valid cross linker for some arm variants? A
>> architecture specific bootstrap one is needed?
>>
>> 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?
>>
>> Note: I got the questions from reading the output in:
>>
>> # ld.lld
>> ld.lld: error: no input files
>> ld.lld: error: target emulation unknown: -m or at least one .o file required
>>
>> 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.
>>
>> (ld.lld does not take -target as an argument.)
>>
> 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.
Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based.
Intersting.
But I took Ed M.'s text to be based on the .meta file where
he listed:
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
-m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1 -o
zfs.ko.full zfs.kld
The implication would be that ld was then directly
invoked instead of via cc (clang).
Looking at a armv7 build I happen to have around:
# more
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/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-NODBG/modules/usr/src/sys/modules/zfs/zfs.ko.full.meta
CMD ld -m aarch64elf -Bshareable -znotext -d -warn-common --build-id=sha1 -o
zfs.ko.full zfs.kld
CWD
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/modules/usr/src/sys/modules/zfs
TARGET zfs.ko.full
-- command output --
It looks like ld was directly invoked instead of being
done via a cc command for my amd64 -> armv7 cross build
example.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard wrote:
> On 2018-Aug-16, at 6:38 AM, Ed Maste wrote:
>
> > On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
> > wrote:
> >>
> >> Is the link command itself available? (The .../sys/*/kernel.full.meta
> >> likely has it if it is still around.)
> >
> > 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:
> >
> > /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/
> freebsd11-amd64/tmp/usr/bin/ld
> > -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
> > -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.
>
> So ld.lld is not a valid cross linker for some arm variants? A
> architecture specific bootstrap one is needed?
>
> 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?
>
> Note: I got the questions from reading the output in:
>
> # ld.lld
> ld.lld: error: no input files
> ld.lld: error: target emulation unknown: -m or at least one .o file
> required
>
> 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.
>
> (ld.lld does not take -target as an argument.)
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.
Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 2018-Aug-16, at 6:38 AM, Ed Maste wrote:
> On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
> wrote:
>>
>> Is the link command itself available? (The .../sys/*/kernel.full.meta
>> likely has it if it is still around.)
>
> 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:
>
> /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
> -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
> -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.
So ld.lld is not a valid cross linker for some arm variants? A
architecture specific bootstrap one is needed?
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?
Note: I got the questions from reading the output in:
# ld.lld
ld.lld: error: no input files
ld.lld: error: target emulation unknown: -m or at least one .o file required
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.
(ld.lld does not take -target as an argument.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
wrote:
>
> Is the link command itself available? (The .../sys/*/kernel.full.meta
> likely has it if it is still around.)
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:
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
-m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
-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.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
[Replying from the intended Email address, rather
than the one I accidentally used originally.]
On 2018-Aug-11, at 5:05 PM, Warner Losh wrote:
> On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard
> wrote:
> On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
> >
> > On 11 Aug 2018, at 19:31, Warner Losh wrote:
> >>
> >> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
> >> On 11 Aug 2018, at 16:55, Warner Losh wrote:
> >>>
> >>> It looks like armv5 clang bogusly uses lld:
> >>>
> >>> From a 'make buildkernel' of the RT1310 kernel config:
> >>>
> >>> cc -target arm-gnueabi-freebsd12.0
> > ...
> >>> ld: warning: lld uses extended branch encoding, no object with
> >>> architecture
> >>> supporting feature detected.
> >>> ld: warning: lld may use movt/movw, no object with architecture supporting
> >>> feature detected.
> > ...
>
> Did the build get either of the below notices? Both?
>
> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
> CC=cc matches the source tree. Not bootstrapping a cross-compiler.
>
> This one I have.
>
> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
> LD=ld matches the source tree. Not bootstrapping a cross-linker.
>
> This one I don't.
>
> Warner
So the system-clang needs to find and use the bootstrap-ld.
Interesting. (Hopefully the two distinct builds can not
create any mismatches for such mixed use.)
I'll note that the original Email listed a cc command for
compiling vers.c and the messages about "linking
kernel.full":
PARTIAL QUOTE
cc -target arm-gnueabi-freebsd12.0
--sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp
-B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c
. . .
-std=iso9899:1999 -Werror vers.c
linking kernel.full
ld: warning: lld uses extended branch encoding, no object with architecture
supporting feature detected.
ld: warning: lld may use movt/movw, no object with architecture supporting
feature detected.
. . .
END PARTIAL QUOTE
Is the link command itself available? (The .../sys/*/kernel.full.meta
likely has it if it is still around.)
> ?
>
> (The example text was taken from an amd64 -> aarch64 cross build.)
>
> >> Host is amd64. Target is arm. No src.conf. Did a full buildworld
> >> TARGET=arm a few days ago. /usr/bin/ld is lld.
> >
> > Okay, so in the above "cc" command, can you somehow figure out which cc
> > executable it is using? And please add a -v to the "linking kernel.full"
> > command line, so it shows exactly which linker it runs?
> >
> > I have the idea that it is preferring your /usr/bin/ld over
> > ${WORLDTMP}/usr/bin/ld...
>
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard <
mark.mill...@nexustechnology.com> wrote:
> On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
> >
> > On 11 Aug 2018, at 19:31, Warner Losh wrote:
> >>
> >> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
> >> On 11 Aug 2018, at 16:55, Warner Losh wrote:
> >>>
> >>> It looks like armv5 clang bogusly uses lld:
> >>>
> >>> From a 'make buildkernel' of the RT1310 kernel config:
> >>>
> >>> cc -target arm-gnueabi-freebsd12.0
> > ...
> >>> ld: warning: lld uses extended branch encoding, no object with
> architecture
> >>> supporting feature detected.
> >>> ld: warning: lld may use movt/movw, no object with architecture
> supporting
> >>> feature detected.
> > ...
>
> Did the build get either of the below notices? Both?
>
> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined
> that CC=cc matches the source tree. Not bootstrapping a cross-compiler.
>
This one I have.
> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
> LD=ld matches the source tree. Not bootstrapping a cross-linker.
>
This one I don't.
Warner
> ?
>
> (The example text was taken from an amd64 -> aarch64 cross build.)
>
> >> Host is amd64. Target is arm. No src.conf. Did a full buildworld
> TARGET=arm a few days ago. /usr/bin/ld is lld.
> >
> > Okay, so in the above "cc" command, can you somehow figure out which cc
> > executable it is using? And please add a -v to the "linking kernel.full"
> > command line, so it shows exactly which linker it runs?
> >
> > I have the idea that it is preferring your /usr/bin/ld over
> > ${WORLDTMP}/usr/bin/ld...
>
>
>
> ===
>
> Mark Millard
> Nexus Technology, Inc.
> 78 Northeastern Blvd., Unit #2
> Nashua NH 03062
>
> 877-595-8116 x821
>
> mark.mill...@nexustechnology.com
>
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
[Resent from the right account. I wish I could remove the prior send.]
On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
>
> On 11 Aug 2018, at 19:31, Warner Losh wrote:
>>
>> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
>> On 11 Aug 2018, at 16:55, Warner Losh wrote:
>>>
>>> It looks like armv5 clang bogusly uses lld:
>>>
>>> From a 'make buildkernel' of the RT1310 kernel config:
>>>
>>> cc -target arm-gnueabi-freebsd12.0
> ...
>>> ld: warning: lld uses extended branch encoding, no object with architecture
>>> supporting feature detected.
>>> ld: warning: lld may use movt/movw, no object with architecture supporting
>>> feature detected.
> ...
Did the build get either of the below notices? Both?
make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
LD=ld matches the source tree. Not bootstrapping a cross-linker.
?
(The example text was taken from an amd64 -> aarch64 cross build.)
>> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm
>> a few days ago. /usr/bin/ld is lld.
>
> Okay, so in the above "cc" command, can you somehow figure out which cc
> executable it is using? And please add a -v to the "linking kernel.full"
> command line, so it shows exactly which linker it runs?
>
> I have the idea that it is preferring your /usr/bin/ld over
> ${WORLDTMP}/usr/bin/ld...
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net
Re: Broken arm support in clang now?
On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
>
> On 11 Aug 2018, at 19:31, Warner Losh wrote:
>>
>> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
>> On 11 Aug 2018, at 16:55, Warner Losh wrote:
>>>
>>> It looks like armv5 clang bogusly uses lld:
>>>
>>> From a 'make buildkernel' of the RT1310 kernel config:
>>>
>>> cc -target arm-gnueabi-freebsd12.0
> ...
>>> ld: warning: lld uses extended branch encoding, no object with architecture
>>> supporting feature detected.
>>> ld: warning: lld may use movt/movw, no object with architecture supporting
>>> feature detected.
> ...
Did the build get either of the below notices? Both?
make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
LD=ld matches the source tree. Not bootstrapping a cross-linker.
?
(The example text was taken from an amd64 -> aarch64 cross build.)
>> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm
>> a few days ago. /usr/bin/ld is lld.
>
> Okay, so in the above "cc" command, can you somehow figure out which cc
> executable it is using? And please add a -v to the "linking kernel.full"
> command line, so it shows exactly which linker it runs?
>
> I have the idea that it is preferring your /usr/bin/ld over
> ${WORLDTMP}/usr/bin/ld...
===
Mark Millard
Nexus Technology, Inc.
78 Northeastern Blvd., Unit #2
Nashua NH 03062
877-595-8116 x821
mark.mill...@nexustechnology.com
smime.p7s
Description: S/MIME cryptographic signature
Re: Broken arm support in clang now?
On 11 Aug 2018, at 19:31, Warner Losh wrote:
>
> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
> On 11 Aug 2018, at 16:55, Warner Losh wrote:
> >
> > It looks like armv5 clang bogusly uses lld:
> >
> > From a 'make buildkernel' of the RT1310 kernel config:
> >
> > cc -target arm-gnueabi-freebsd12.0
...
> > ld: warning: lld uses extended branch encoding, no object with architecture
> > supporting feature detected.
> > ld: warning: lld may use movt/movw, no object with architecture supporting
> > feature detected.
...
> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm a
> few days ago. /usr/bin/ld is lld.
Okay, so in the above "cc" command, can you somehow figure out which cc
executable it is using? And please add a -v to the "linking kernel.full"
command line, so it shows exactly which linker it runs?
I have the idea that it is preferring your /usr/bin/ld over
${WORLDTMP}/usr/bin/ld...
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: Broken arm support in clang now?
On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote: > On 11 Aug 2018, at 16:55, Warner Losh wrote: > > > > It looks like armv5 clang bogusly uses lld: > > > > From a 'make buildkernel' of the RT1310 kernel config: > > > > cc -target arm-gnueabi-freebsd12.0 > > --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp > > -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe > > -g -nostdinc -I. -I/usr/home/imp/git/head/sys > > -I/usr/home/imp/git/head/sys/contrib/ck/include > > -I/usr/home/imp/git/head/sys/contrib/libfdt > > -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL > > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te > > -funwind-tables -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > > -Wno-error-tautological-compare -Wno-error-empty-body > > -Wno-error-parentheses-equality -Wno-error-unused-function > > -Wno-error-pointer-sign -Wno-error-shift-negative-value > > -Wno-address-of-packed-member -mfpu=none -std=iso9899:1999 -Werror > vers.c > > linking kernel.full > > ld: warning: lld uses extended branch encoding, no object with > architecture > > supporting feature detected. > > ld: warning: lld may use movt/movw, no object with architecture > supporting > > feature detected. > > text data bss dechex filename > > 3448944 176776 655360 4281080 0x4152f8 kernel.full > > > > Any clues on how I can track this down? > > What does /usr/bin/ld -v output? As far as I can see, MK_LLD_BOOTSTRAP > and MK_LLD_IS_LD are only enabled by default for aarch64 and amd64. So > do you have any of those settings in your src.conf or environment? > Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm a few days ago. /usr/bin/ld is lld. Warner > ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 11 Aug 2018, at 16:55, Warner Losh wrote: > > It looks like armv5 clang bogusly uses lld: > > From a 'make buildkernel' of the RT1310 kernel config: > > cc -target arm-gnueabi-freebsd12.0 > --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp > -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe > -g -nostdinc -I. -I/usr/home/imp/git/head/sys > -I/usr/home/imp/git/head/sys/contrib/ck/include > -I/usr/home/imp/git/head/sys/contrib/libfdt > -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te > -funwind-tables -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -mfpu=none -std=iso9899:1999 -Werror vers.c > linking kernel.full > ld: warning: lld uses extended branch encoding, no object with architecture > supporting feature detected. > ld: warning: lld may use movt/movw, no object with architecture supporting > feature detected. > text data bss dechex filename > 3448944 176776 655360 4281080 0x4152f8 kernel.full > > Any clues on how I can track this down? What does /usr/bin/ld -v output? As far as I can see, MK_LLD_BOOTSTRAP and MK_LLD_IS_LD are only enabled by default for aarch64 and amd64. So do you have any of those settings in your src.conf or environment? -Dimitry signature.asc Description: Message signed with OpenPGP
Broken arm support in clang now?
It looks like armv5 clang bogusly uses lld: >From a 'make buildkernel' of the RT1310 kernel config: cc -target arm-gnueabi-freebsd12.0 --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/home/imp/git/head/sys -I/usr/home/imp/git/head/sys/contrib/ck/include -I/usr/home/imp/git/head/sys/contrib/libfdt -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te -funwind-tables -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mfpu=none -std=iso9899:1999 -Werror vers.c linking kernel.full ld: warning: lld uses extended branch encoding, no object with architecture supporting feature detected. ld: warning: lld may use movt/movw, no object with architecture supporting feature detected. text data bss dechex filename 3448944 176776 655360 4281080 0x4152f8 kernel.full Any clues on how I can track this down? Warner ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
