From owner-freebsd-toolchain@freebsd.org Thu Aug 16 18:08:49 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AFCC1071357 for ; Thu, 16 Aug 2018 18:08:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-22.consmr.mail.gq1.yahoo.com (sonic311-22.consmr.mail.gq1.yahoo.com [98.137.65.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 230D070D85 for ; Thu, 16 Aug 2018 18:08:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: C2sExSwVM1mFWonf36JoIR.UH4U5HBXYzUxKKrVRTwO_Zetf5pXY5HT9E4iR8tI tClrf_WZmUdH8Vt.mlb47FqzIDYESCmYAz1BGpsJvvN1md2bmk8GvToN3Tbs2.uRK.FxDvZQykSV DCbkwFJB0HriC_E7nbEiSnkx7mbnx0slFTn9DFiBwM9xAd0ZpZ0yDf2J1KHl8fHZafhLKJkTqVyt ITpJvzFQdZh4b8c3S5o2GNz7TlkDVtG91XqbGxXXh3aJBw1lIpUbfwBz76jLofdI7YEYi_XQ.OTM BzNp8dACO4D8IAXHLg.cyaubUkul4qZ6eHk9RHkLHqWH6Fae6tGP6lG3Xe3YxjmcaH1vaQ0PEJOy pIZje7nH6GioVLU40eGtwnDtNUah7S7Wy7duyxX9nICAwMRwknIdDzggN8CnPLFOt0dyjcRGCgYj sgk1ugSNriebi7XpsvcUAzkm8ohkrpTre1l2K0qB4_QWXLGUfCXE9GDgl6StAbst8orN8JwTYtLg rdfLV9eJEaGtMbLqo7lM2DSW2ST662_mmZLiQzK0yZnCbGfuxMIyh.2iqpCPvR_0EBtMyV5E8zga XVP3xsJdhIWbdAFrxKNLYiJHD4o_4_BYspKThMv44UNEtuE50DHzG1aDpfJxYwMNFgqf8L.lAQMw IiNRNgxjB5V28Y81HyJgzeXuBOdVkbBLF4bV5LMQqYU9dEVNVBPZMK4.Ha01nM71Dty0xvANphe. UGcnaqZM84fJ8BYLAIpM6uh6OAytwTCtwX1Xs6cEdcHjJUHGbnqfI9w40XTtBjcyLLHJPzbaaXOY deFOudkKJoD.uOm8Is.Kh_LXbD9bVxUJx2WG7sNLqMT1VhbCTaB6IIKDd0RDFICUT3PcXbgKXQI2 1DX9N.WkT4dXuYfxDns4uThgk36DEe8YOi3mQDBd.fkkVmHJGc47pIJleTsNXqxfZ3bL90ST7Oco z4o9g._Oe84NZG8rjolVKFedQsJgusp4sjqtT0w4cgLwdYBqGr7jL0frK_TxvboGuWchKjbFsps4 3Kr110B2N Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Aug 2018 18:08:42 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9de6fe09bd0e4efa25c4f3ff5f328bb8; Thu, 16 Aug 2018 18:08:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Broken arm support in clang now? From: Mark Millard In-Reply-To: Date: Thu, 16 Aug 2018 11:08:39 -0700 Cc: Warner Losh , "freebsd-toolchain@FreeBSD.org" , Dimitry Andric , Bryan Drewery Content-Transfer-Encoding: quoted-printable Message-Id: <70A9144F-EBD8-46F6-8E2F-98A630A897E4@yahoo.com> References: <1880880F-9D9D-47E0-A7A4-5369A3770F89@FreeBSD.org> <8B467E75-A6D3-41A5-8EA1-4DDFE0E14CC5@nexustechnology.com> <230C1E7D-04DB-4E45-8A40-F6B2F5E557E9@yahoo.com> <86844298-1268-4F5E-A6CD-64CADC022FB9@yahoo.com> To: Ed Maste X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 18:08:49 -0000 [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: >>=20 >> On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard = wrote: >>> On 2018-Aug-16, at 6:38 AM, Ed Maste wrote: >>>=20 >>>> On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain >>>> 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)