> On 2018-Aug-16, at 7:16 AM, Warner Losh <imp at bsdimp.com> wrote:
>
> 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:
>>
>> > On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
>> > <freebsd-toolchain at freebsd.org> 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"
