From owner-freebsd-current@freebsd.org Tue Mar 27 17:15:27 2018 Return-Path: Delivered-To: freebsd-current@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 4F8CBF6C5AF; Tue, 27 Mar 2018 17:15:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D35DA72D7B; Tue, 27 Mar 2018 17:15:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x231.google.com with SMTP id v13so158338iob.6; Tue, 27 Mar 2018 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KTkmPFAan1r46/P9C+Y7T9LIgNNnZREVZJ8KGHARyz8=; b=C59DSrs0QQd/czQ1PBlIi1Z8EJce/ggSFuMKBKPK+sJ0jVmAGQSnaD3sEOU5fS5KWz Ka7lfjbulyqQSJujaokHnSGD+w74mcQAjnseZGFbMUsa4+lXndfCZpYs3CsDf9pxRuOG HT9IwFyIOR6+mav896PSBGCVa7YjV6pMlV8ttJuKDWeP2NEmBj0vB8jdDnj3+ssq0Prx kUcjLzrUoRuIN/+63JrkzxEqkqm28UfGsFj6kfnEfwxZIUJPh1Ui1cHM2g3uxG2HofBV I5ABS3zC/7cEoOWGDZLpKxpRbZddR8iaT868tbCP9KVMiriN7YvF/ER2sVnXSmUADwpD S0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KTkmPFAan1r46/P9C+Y7T9LIgNNnZREVZJ8KGHARyz8=; b=dVTzTlwRRfVRwXUaWuLQ+PttwhqKgSweZ+DJFNj39PPT5M67br456U9lGuRBbkDwlT eKtsOBegXEPdzYDaOfTMJCrvfeHZvaEYFBc6mFGUq+jWIa/inqImTyBQf/MsYAvr6mkh otz9DyARG8lgHa8qBrpyzozLovhkuXIGBUBX5hrcR/wm6KZ9uqm+3TVseYv52Jchgdug zv/zh0u+stRXoudI34md+LWj3JzHFmQKvE3tlg2facQAYErqSux/Yq+oJytuFBbIeQ5H dlNsl+23xVfb65rihc9XN7nvkYnLWEwUCdfYY4AGlBqfYSbciyBRI1ChvQ/PJ3HUvKiy r51Q== X-Gm-Message-State: AElRT7Hgv3dDR6lvPX6rW+K7toX3d4iiuYAKhC0x86Sd5HApdnQ0bqLN bthiNmTO/Umo2W+kF6wMZ5hpkO1aRkhNQTKx8BfzPwOm X-Google-Smtp-Source: AG47ELsvBh7+qaUoaEmdZvFj/ClzwuOPMpUK9w4H5eSJm2nFrFYY7+ldrbKQMJDOUP48VM6ZBchPksq+tqGVI92qxhc= X-Received: by 10.107.20.213 with SMTP id 204mr42522645iou.239.1522170926126; Tue, 27 Mar 2018 10:15:26 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.130.197 with HTTP; Tue, 27 Mar 2018 10:15:05 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 27 Mar 2018 13:15:05 -0400 X-Google-Sender-Auth: sektya6LYFVR1ieeDT__ysn16kU Message-ID: Subject: Re: Heads-up: linker (lld) changes for amd64 coming soon To: Antoine Brodin Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:15:27 -0000 On 27 March 2018 at 02:20, Antoine Brodin wrote: >> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the >> first use being Supervisor Mode Access Prevention (SMAP) on amd64. >> This relies on linker support that is available in the in-tree lld and >> in contemporary binutils ld.bfd from ports, but not in the in-tree >> ld.bfd 2.17.50. > > I have no concerns about 1. OK. My guess is I won't get any other feedback on this one until it makes it into a release. I suspect kib will commit this part later this week or early next week. >> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, >> and thus the linker used for linking ports. I plan to switch this to >> default on. >> > > About 2., I am concerned that changes breaking a large number of > ports are committed without portmgr@ approval. > If WITH_LLD_IS_LD is committed as is on amd64, packages for head > won't be published as it doesn't meet our current criteria for > publication. Fair enough - this was the reason I sent the email. I've now gone through and submitted a PR for for each failure that did not already have one. I've also added LLD_UNSAFE to a few ports where where it was straightforward. In this batch of PRs I noticed four main issues: 1. Ports that pass compiler flags, such as -fPIC, to the linker. lld has more strict command-line parsing and rejects these invalid invocations, while ld.bfd happily creates bogus output (e.g. a shared library with a DT_AUXILIARY entry of "PIC"). PR 221808 has a reasonable discussion of this issue. 2. lld has no built-in search paths (/lib, /usr/lib). Normally the linker is invoked from the compiler driver, which provides default search paths. If lld is invoked directly then library search paths must be specified explicitly with -L/lib -L/usr/lib. 3. Shared library protected visibility symbol preemption. 4. lld does not have a built-in default output target. For the common use of the linker (linking individual .o objects into an executable or shared object) lld infers the target from the first object file. However, when the linker is used to convert an arbitrary binary file into an ELF ojbect (via -r -b binary) lld needs the output target to be specified explicitly with -m. The vast majority of skipped ports in the exp-run come from two failures: lang/ghc (PR226872) and lang/fpc (222172). The PR for lang/ghc reports that the current released version of ghc mentions improved lld support; I hope the port update will solve this issue. I submitted a bug report upstream for lang/fpc about one fpc bug that affected lld, and that issue has now been resolved upstream. We'll need to check again once the port is updated.