From owner-svn-src-head@freebsd.org Sat Jan 13 01:46:33 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2D0DE66901; Sat, 13 Jan 2018 01:46:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90B846B6CE; Sat, 13 Jan 2018 01:46:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (astound-66-234-199-215.ca.astound.net [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 41F6310A7DB; Fri, 12 Jan 2018 20:46:31 -0500 (EST) From: John Baldwin To: Ed Maste Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327783 - head/share/mk Date: Fri, 12 Jan 2018 17:46:22 -0800 Message-ID: <3584752.ozb5ohFTAi@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <201801102028.w0AKS1UA000454@repo.freebsd.org> References: <201801102028.w0AKS1UA000454@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 12 Jan 2018 20:46:31 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 01:46:33 -0000 On Wednesday, January 10, 2018 08:28:01 PM Ed Maste wrote: > Author: emaste > Date: Wed Jan 10 20:28:01 2018 > New Revision: 327783 > URL: https://svnweb.freebsd.org/changeset/base/327783 > > Log: > Enable ld.lld as bootstrap linker by default on amd64 > > For some time we have been planning to migrate to LLVM's lld linker. > Having a man page was the last blocking issue for using ld.lld to link > the base system kernel + userland, now addressed by r327770. Link the > kernel and userland libraries and binaries with ld.lld by default, for > additional test coverage. > > This has been a long time in the making. On 2013-04-13 I submitted an > upstream tracking issue in LLVM PR 23214: [META] Using LLD as FreeBSD's > system linker. Since then 85 individual issues were identified, and > submitted as dependencies. These have been addressed along with two > and a half years of other lld development and improvement. > > I'd like to express deep gratitude to upstream lld developers Rui > Ueyama, Rafael Espindola, George Rimar and Davide Italiano. They put in > substantial effort in addressing the issues we found affecting > FreeBSD/amd64. > > To revert to using ld.bfd as the bootstrap linker, in /etc/src.conf set > > WITHOUT_LLD_BOOTSTRAP=yes > > If you need to set this, please follow up with a PR or post to the > freebsd-toolchain mailing list explaining how default WITH_LLD_BOOTSTRAP > failed for your use case. > > Note that GNU ld.bfd is still installed as /usr/bin/ld, and will still > be used for linking ports. ld.lld can be installed as /usr/bin/ld by > setting in /etc/src.conf > > WITH_LLD_IS_LLD=yes > > A followup commit will set WITH_LLD_IS_LD by default, possibly after > Clang/LLVM/lld 6.0 is merged to FreeBSD. > > Release notes: Yes > Sponsored by: The FreeBSD Foundation FYI, due to a quirk of how we load kernel modules on amd64 in such a way that doesn't really honor the ELF spec (but is self-consistent in the kernel and loader) and the fact that LLD doesn't sort sections the way BFD does, this change has confused kgdb such that it can compute different address for symbols. I dont think i386 is affected, only amd64. I've started on a fix, but my first attempt to boot it resulted in no modules loading anymore and it's time to go home for the day. :-P I'll try to resolve this early next week. If you need to use kgdb on amd64 with kernel modules, you will have to build with an external toolchain (the old ld.bfd can't cope with the kernel ifunc stuff). -- John Baldwin