From owner-freebsd-current@freebsd.org Tue Mar 27 02:15:01 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 F3235F645B8; Tue, 27 Mar 2018 02:15:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 90DDC84F39; Tue, 27 Mar 2018 02:15:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x231.google.com with SMTP id h143-v6so5498929ita.4; Mon, 26 Mar 2018 19:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=vERJlQCInH5avX7G0mt4XuzWHKG2QRQA8VXjgP0l5L8=; b=l/xvyjVgtyZDv6pI6/6Diz3TutpPv7wKoTc0oSN8Oovu2oxOsQz9LureuP2tGiC7la AfsJwy2vgaEnFzNiFHMcnGq4xvtynScYVEVQUKUnVj9tQI0QRtR9a7rqVNNXEvgkqmk/ fUf3+Bw9bxAGOB7M7J5p1V8D8MDjYrLoaWsfciAlU5Ro6wu94erHT7v7LsLeKl2UnXaK jwz8rr3hwC25+SmWHVy1/5X0jIQOKCKbW8hAx35Of3RFMVlr8O+ri+nd2AfT4MQwYpEz vY/4IWgf6a9tMGLM+rWYLy0/Iq+ZjqjCOJt4Yhx7t5xzLQVEHQ+C4DQ5jrkCcH1B5CA1 Nihw== 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:from:date:message-id:subject :to; bh=vERJlQCInH5avX7G0mt4XuzWHKG2QRQA8VXjgP0l5L8=; b=lf+83CSL/wO9pXIMic1LccdWu/XFS9M2GkBd44nnhS76LdPmEUXXpdePLqIYd4xC9z 3VzwqlEUWCBxSHMILV9ZxUGEP07dRz5P7AOYm/b64EU7r16lWBB03GYH6BTcgWrpV7wE K4V8mbqDcI3V2hapv0TITiWM8vNvJq9P81b4zWNA0CzCZHRMSQYAlBkAzZbGmdGRCURE d7W31po/8egzcYr0QqEP35W84fXxiyj8LBf6zUOfF7iNo5B5RrVP6GuzEAthyUQSCBB+ 3WPnBPbFP5Nv2OJ9X8omZqNKHEM5A/j3U7nUzpxTQTA+Ps8Sg4fIzu0ZaYZVVbXvrYAt obvQ== X-Gm-Message-State: AElRT7EfIXG8+ZCdEZpIhaA0SL0kQ3l3iCWJFcRB4DPt/qB8K0zLY9q9 fDn+0wHO8YQul5aWvsaGgjKhi7Fx1swYbqDm6w4F113Q X-Google-Smtp-Source: AIpwx4/mZ4zDrob1gSNupGbUEOb0/iJUVxeUFcHBWXGoQRvQBZK8XfsmWRbJlZw6AI2yZD1CV3udUOcd60OBOyKLDNU= X-Received: by 2002:a24:dfc3:: with SMTP id r186-v6mr137905itg.114.1522116899786; Mon, 26 Mar 2018 19:14:59 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.20.200 with HTTP; Mon, 26 Mar 2018 19:14:33 -0700 (PDT) From: Ed Maste Date: Mon, 26 Mar 2018 22:14:33 -0400 X-Google-Sender-Auth: 30nkv9Im5Z22rzvi_0aqPBa-HJQ Message-ID: Subject: Heads-up: linker (lld) changes for amd64 coming soon To: 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 02:15:01 -0000 Some changes related to the amd64 linker are nearly ready to be committed (within a week or three), so I'm sending this notice to request any final comments or concerns before these changes are made. 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. Right now we use lld as the default bootstrap linker for amd64 in -CURRENT -- that is, the kernel, and userland libraries and binaries are linked with lld. To revert to ld.bfd for amd64 the build-time knob WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work for amd64 kernels (and will be added to BROKEN_OPTIONS). 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. Most ports build just fine when lld is the system linker, but a few encounter trouble: some of the ports rely on options not supported by lld, rely on specific quirks of ld.bfd's implementation, or have a buggy linker invocation that is silently ignored by ld.bfd. The majority of such ports have now been adapted to work with lld or configured to use ld.bfd as the linker, but there are a small number of failing ports that do not provide a way to use other than the default system linker /usr/bin/ld. The outstanding issues can be found in the ports exp-run for lld as /usr/bin/ld, PR214864. Please follow up if you have any concerns or comments about these upcoming changes.