From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 15:46:32 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46FF2337 for ; Tue, 16 Dec 2014 15:46:32 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11297274 for ; Tue, 16 Dec 2014 15:46:32 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id z20so7060917igj.16 for ; Tue, 16 Dec 2014 07:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=KlDcujQWdVdgE1t6GdwgFBJ+796TbwSxHYYfRHLe9Ak=; b=WcizPtk60TYw5KvrIuNYInMxQazX9S60h7zbLZFOovSZHA7ub2g1jatfM8k+UV2yFC /qgwSro3lmTtM0Opwx5wfnuqJaT67EwCcpDluWQTVLxSP6oyNu6Li989Br36Bw+V5C6U P8lYvWsKTOhl5vRr3Z8aap2QWi6fmKlHJ5SILD87MaRkcPCBpfMfOdBlbEbYowRlwnuF 8vIDQw1F5qeGJoSL9ca0o1v/c0h+2RLv+FtCv/MhIokaR2NGHamWiX9APbSf8w/A7b8U X7Hdxqh6IH8OaxzrvdYIyGKuO8XB29tODQVUJ153vN2SsBTAV1s1wIEC//JuD1FHRQ3u 055w== X-Received: by 10.50.45.100 with SMTP id l4mr3237426igm.40.1418744791507; Tue, 16 Dec 2014 07:46:31 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Tue, 16 Dec 2014 07:46:11 -0800 (PST) From: Ed Maste Date: Tue, 16 Dec 2014 10:46:11 -0500 X-Google-Sender-Auth: 1E6obYW12MEg_975HRiFRv3GOkI Message-ID: Subject: Migration to dynamic libs for llvm and clang To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:46:32 -0000 One of goals for the toolchain prior to the FreeBSD 11 branch is to create a libllvm.so and libclang.so for use by all of the LLVM family tools installed in the base system. This message is just a heads-up in case anyone has questions or comments on the idea. We currently build a large number of static libs for the llvm and clang components, which are reused in a number of tools in the LLVM family. The resulting binaries end up quite large, and as a group require a lot of disk space. For example, LLDB includes a copy of Clang, used as its expression parser. As a result, on my desktop /usr/bin/clang and /usr/bin/lldb are both 27MB. Over time we may add additional LLVM family tools (e.g., llvm-objdump), and this will help avoid excessive bloat as we do so. I expect libllvm.so and libclang.so will go in /usr/lib/private. From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 15:58:51 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3447272F; Tue, 16 Dec 2014 15:58:51 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F06573F3; Tue, 16 Dec 2014 15:58:50 +0000 (UTC) Received: from [192.168.1.18] (ABordeaux-259-1-48-189.w109-223.abo.wanadoo.fr [109.223.255.189]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id sBGFwcwR026198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Dec 2014 15:58:41 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host ABordeaux-259-1-48-189.w109-223.abo.wanadoo.fr [109.223.255.189] claimed to be [192.168.1.18] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Migration to dynamic libs for llvm and clang From: David Chisnall In-Reply-To: Date: Tue, 16 Dec 2014 15:58:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> References: To: Ed Maste X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:58:51 -0000 Hi Ed, Please can we have a name other than libclang, to avoid name collisions = and confusion with, uh, libclang? libcfe maybe? David On 16 Dec 2014, at 15:46, Ed Maste wrote: > One of goals for the toolchain prior to the FreeBSD 11 branch is to > create a libllvm.so and libclang.so for use by all of the LLVM family > tools installed in the base system. This message is just a heads-up in > case anyone has questions or comments on the idea. >=20 > We currently build a large number of static libs for the llvm and > clang components, which are reused in a number of tools in the LLVM > family. The resulting binaries end up quite large, and as a group > require a lot of disk space. For example, LLDB includes a copy of > Clang, used as its expression parser. As a result, on my desktop > /usr/bin/clang and /usr/bin/lldb are both 27MB. >=20 > Over time we may add additional LLVM family tools (e.g., > llvm-objdump), and this will help avoid excessive bloat as we do so. >=20 > I expect libllvm.so and libclang.so will go in /usr/lib/private. > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 16:04:19 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 470AD7AC; Tue, 16 Dec 2014 16:04:19 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3FFB695; Tue, 16 Dec 2014 16:04:18 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::949f:2cd4:f2b0:7a2d] (unknown [IPv6:2001:7b8:3a7:0:949f:2cd4:f2b0:7a2d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C35CEB80A; Tue, 16 Dec 2014 17:04:09 +0100 (CET) Subject: Re: Migration to dynamic libs for llvm and clang Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5C008411-5CEB-4152-A2A4-0B24335EFDC1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> Date: Tue, 16 Dec 2014 17:04:06 +0100 Message-Id: References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:04:19 -0000 --Apple-Mail=_5C008411-5CEB-4152-A2A4-0B24335EFDC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Dec 2014, at 16:58, David Chisnall wrote: > On 16 Dec 2014, at 15:46, Ed Maste wrote: >> One of goals for the toolchain prior to the FreeBSD 11 branch is to >> create a libllvm.so and libclang.so for use by all of the LLVM family >> tools installed in the base system. This message is just a heads-up = in >> case anyone has questions or comments on the idea. >>=20 >> We currently build a large number of static libs for the llvm and >> clang components, which are reused in a number of tools in the LLVM >> family. The resulting binaries end up quite large, and as a group >> require a lot of disk space. For example, LLDB includes a copy of >> Clang, used as its expression parser. As a result, on my desktop >> /usr/bin/clang and /usr/bin/lldb are both 27MB. >>=20 >> Over time we may add additional LLVM family tools (e.g., >> llvm-objdump), and this will help avoid excessive bloat as we do so. >>=20 >> I expect libllvm.so and libclang.so will go in /usr/lib/private. > Hi Ed, >=20 > Please can we have a name other than libclang, to avoid name = collisions and confusion with, uh, libclang? libcfe maybe? This is precisely why the libs should go into /usr/lib/private, so as to avoid collisions with any upstream libraries installed by e.g. ports (or when you manually run "make install" after building). I'm not sure we want to go the 'libbsdfoo.so' route again, as Baptiste tried this before, and seems to have reversed it again. :) That said, I agree with the general idea, but one of the first things we should decide is whether this will be optional or not. Having to maintain yet another WITH_CLANG_FOO option is burdensome... -Dimitry --Apple-Mail=_5C008411-5CEB-4152-A2A4-0B24335EFDC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSQV/oACgkQsF6jCi4glqMVtQCgj7NSJe6VwmTHdGDWQW7qqUfY hSkAn1B6K8m9DrhECRHKXVsfWqgTqAM1 =NUpV -----END PGP SIGNATURE----- --Apple-Mail=_5C008411-5CEB-4152-A2A4-0B24335EFDC1-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 16:15:16 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B461A87A; Tue, 16 Dec 2014 16:15:16 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B65C7DA; Tue, 16 Dec 2014 16:15:15 +0000 (UTC) Received: from [192.168.1.18] (ABordeaux-259-1-48-189.w109-223.abo.wanadoo.fr [109.223.255.189]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id sBGGFAmH026276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Dec 2014 16:15:13 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host ABordeaux-259-1-48-189.w109-223.abo.wanadoo.fr [109.223.255.189] claimed to be [192.168.1.18] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Migration to dynamic libs for llvm and clang From: David Chisnall In-Reply-To: Date: Tue, 16 Dec 2014 16:15:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:15:16 -0000 On 16 Dec 2014, at 16:04, Dimitry Andric wrote: > This is precisely why the libs should go into /usr/lib/private, so as = to > avoid collisions with any upstream libraries installed by e.g. ports = (or > when you manually run "make install" after building). That's still potentially an issue if we add local tools that use = libclang APIs (which we may well do). > I'm not sure we want to go the 'libbsdfoo.so' route again, as Baptiste > tried this before, and seems to have reversed it again. :) Upstream doesn't call it libclang (that's the name of the library with a = stable C ABI, which is why I'd like us not to confuse it with something = with a library with an unstable C++ API). They do produce a libLLVM.so = from the LLVM builds and work is underway to have shared library builds = for clang. libLLVM.so could potentially be in /usr/lib in 11 if we have a packaged = base system, as it would allow us to have different .so versions = installed if things demanded them. The point releases guarantee = backwards ABI compatibility, so we can still upgrade to them if = required. > That said, I agree with the general idea, but one of the first things > we should decide is whether this will be optional or not. Having to > maintain yet another WITH_CLANG_FOO option is burdensome... I agree. I'd quite like to see performance numbers for the compiler. I = think I saw about a 10% overhead for buildworld last time I tried, but = that was a couple of years ago. David From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 16:32:33 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECED9E0C; Tue, 16 Dec 2014 16:32:32 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7A7B9E1; Tue, 16 Dec 2014 16:32:32 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::949f:2cd4:f2b0:7a2d] (unknown [IPv6:2001:7b8:3a7:0:949f:2cd4:f2b0:7a2d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 602AFB80A; Tue, 16 Dec 2014 17:32:28 +0100 (CET) Subject: Re: Migration to dynamic libs for llvm and clang Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> Date: Tue, 16 Dec 2014 17:32:22 +0100 Message-Id: References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:32:33 -0000 --Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Dec 2014, at 17:15, David Chisnall wrote: >=20 > On 16 Dec 2014, at 16:04, Dimitry Andric wrote: >> This is precisely why the libs should go into /usr/lib/private, so as = to >> avoid collisions with any upstream libraries installed by e.g. ports = (or >> when you manually run "make install" after building). >=20 > That's still potentially an issue if we add local tools that use = libclang APIs (which we may well do). >=20 >> I'm not sure we want to go the 'libbsdfoo.so' route again, as = Baptiste >> tried this before, and seems to have reversed it again. :) >=20 > Upstream doesn't call it libclang (that's the name of the library with = a stable C ABI, which is why I'd like us not to confuse it with = something with a library with an unstable C++ API). They do produce a = libLLVM.so from the LLVM builds and work is underway to have shared = library builds for clang. >=20 > libLLVM.so could potentially be in /usr/lib in 11 if we have a = packaged base system, as it would allow us to have different .so = versions installed if things demanded them. The point releases = guarantee backwards ABI compatibility, so we can still upgrade to them = if required. Unfortunately we already imported quite a lot of ABI-breaking bug fixes. I would prefer only our own tools to be linked against the "FreeBSD" version of libllvm.so/libwhatever.so. > That said, I agree with the general idea, but one of the first things >> we should decide is whether this will be optional or not. Having to >> maintain yet another WITH_CLANG_FOO option is burdensome... >=20 > I agree. I'd quite like to see performance numbers for the compiler. = I think I saw about a 10% overhead for buildworld last time I tried, but = that was a couple of years ago. There is already a WITH_SHARED_TOOLCHAIN option, that defaults to off, but I have had it on since approximately the time Kostik added it. I might just have gotten used to the overhead, if any... I would like to do a bit of testing with that, but my TODO list is rather full at this point, working on the 3.5.0 import. :) -Dimitry --Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSQXp0ACgkQsF6jCi4glqNh0ACfW9fJ/T0pQ73PF1M0QsTx/EuE kUYAoNgYWGJ0XHBhELq20Ko1w7MLZo1M =a2kz -----END PGP SIGNATURE----- --Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 17:39:43 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8A55FFA for ; Tue, 16 Dec 2014 17:39:43 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D7B8144 for ; Tue, 16 Dec 2014 17:39:43 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so14479570pab.12 for ; Tue, 16 Dec 2014 09:39:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=iVOFbIO9ceHVfShH+Ftf5MUnvyZ8QBQ7eg9eRQUR338=; b=EnoOMr8NrECPwGwaKg5/igu1T8d3RZsj3ESkzP2H0C3uknsEMQtAyI2k8RmdRpngX2 hggKhUk3GsMPwDu1ble4cXk20qQitZh3JQCAht9Xsz0ZIc0fBLLO2Ki4bcBA7MmF7pqi 6fW76taBJD44cdSSwqSb4WXe2uERjijJSKpLEkNFbSuIYY2hiDcFQplsCWykNG+EBZga bqhjEBWnuQTwrdKt8Fz+uxD/kALfuT2fE9eOB/jz0ntxkLpPAVwEj8ch2GwB5DGS7e0G Q9ehBG0Z4Ib5deQvgMtPrssIrgxnbyJJsQxM3grWZDrnYDqC43FASZxMEiD8c+ks0pKu pfGw== X-Gm-Message-State: ALoCoQmuUV/yljII8W1a1rkYBTxBrc6jkH0rAprMzYRRjj6kYHAdC94wymv1RgRxjb66i/PJWwfe X-Received: by 10.70.137.238 with SMTP id ql14mr58746090pdb.94.1418751576740; Tue, 16 Dec 2014 09:39:36 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id ml5sm1568465pab.32.2014.12.16.09.39.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 09:39:35 -0800 (PST) Sender: Warner Losh Subject: Re: Migration to dynamic libs for llvm and clang Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EC97E68D-9267-4AAC-B33D-B0D24C51ADF2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Tue, 16 Dec 2014 10:39:32 -0700 Message-Id: <4E3A3DA8-209C-43E1-83D4-928823CCBF04@bsdimp.com> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:39:43 -0000 --Apple-Mail=_EC97E68D-9267-4AAC-B33D-B0D24C51ADF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 16, 2014, at 9:32 AM, Dimitry Andric wrote: >=20 > On 16 Dec 2014, at 17:15, David Chisnall wrote: >>=20 >> On 16 Dec 2014, at 16:04, Dimitry Andric wrote: >>> This is precisely why the libs should go into /usr/lib/private, so = as to >>> avoid collisions with any upstream libraries installed by e.g. ports = (or >>> when you manually run "make install" after building). >>=20 >> That's still potentially an issue if we add local tools that use = libclang APIs (which we may well do). >>=20 >>> I'm not sure we want to go the 'libbsdfoo.so' route again, as = Baptiste >>> tried this before, and seems to have reversed it again. :) >>=20 >> Upstream doesn't call it libclang (that's the name of the library = with a stable C ABI, which is why I'd like us not to confuse it with = something with a library with an unstable C++ API). They do produce a = libLLVM.so from the LLVM builds and work is underway to have shared = library builds for clang. >>=20 >> libLLVM.so could potentially be in /usr/lib in 11 if we have a = packaged base system, as it would allow us to have different .so = versions installed if things demanded them. The point releases = guarantee backwards ABI compatibility, so we can still upgrade to them = if required. >=20 > Unfortunately we already imported quite a lot of ABI-breaking bug = fixes. > I would prefer only our own tools to be linked against the "FreeBSD" > version of libllvm.so/libwhatever.so. :( >> That said, I agree with the general idea, but one of the first things >>> we should decide is whether this will be optional or not. Having to >>> maintain yet another WITH_CLANG_FOO option is burdensome... >>=20 >> I agree. I'd quite like to see performance numbers for the compiler. = I think I saw about a 10% overhead for buildworld last time I tried, = but that was a couple of years ago. >=20 > There is already a WITH_SHARED_TOOLCHAIN option, that defaults to off, > but I have had it on since approximately the time Kostik added it. I > might just have gotten used to the overhead, if any=E2=80=A6 The 10% figure has been relatively constant over the lifetime of shared libraries in FreeBSD. This is the average hit of using shared libraries and everybody accepts that. I doubt time has changed this much at all. > I would like to do a bit of testing with that, but my TODO list is > rather full at this point, working on the 3.5.0 import. :) We should defer testing until after that import :) Warner --Apple-Mail=_EC97E68D-9267-4AAC-B33D-B0D24C51ADF2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkG5VAAoJEGwc0Sh9sBEA9zQQAKA078Sc8X2VT+C6B7YaLBLT uoYXq66Mg6rSN5QU2dJvKMiak7vgYHBEbi4RvjXGPq+TvC9z74AXeQpn1uwLCfUZ T425jHcihhyguq8/Jk9U7KEnB5zBvb3iyIRfpKJUOt2YVHhKzGkruKmOhm2KgoOm v+/hPHnZJh30nJQldywBpQyrz4RC3zhFM6rn9D9S8LthiHa41zkFU595aWbckUWc f0Id2M8Iwcam264ERsc0hUSZKkvQmHdriGA2M0dTuDcgAGwCYJq01U4R3Iqb/fFS PpD9uPYOTUiT7mfbKe3Jbzm7HCaeONVHTZfSLpU62Hre4y4OiShpHmmvTOepiUN0 evBdJ4L1g7yAraLiRucm+kFdUXFzv0RDMH0f+YAtJRZNSAdgIEVvJvVo3j0FVwfB BDW+xuvhN9+XxE9hgptgy0ch/h1eLurHWb6rdHBQU6wU8IddVOmuegV2FI6aaVxi pMC1dkaY/ZmfyjhxvokIdNxhNhcv10ilG0AIklGm7vl8jW3vJzv2D5LhiPI4UbOh yb/U9oeiFdq249/Lgsr8Vdt0lv+eUZIYkIgIaer8qMlkAU5VSFcODzEmsCPQbheH xJw70riuwqjXHRDZcx8syRXOQkBh3EWA1bSPBouU57h3/w900JyxlmT0qF0PCPLM 51u1HZovittYIJiipSNz =Rdws -----END PGP SIGNATURE----- --Apple-Mail=_EC97E68D-9267-4AAC-B33D-B0D24C51ADF2-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 17:44:51 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F7F61E7; Tue, 16 Dec 2014 17:44:51 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53BBB21B; Tue, 16 Dec 2014 17:44:51 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id tr6so13426317ieb.3 for ; Tue, 16 Dec 2014 09:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=7/OjsAx+xQPj5536lUstUzewgS9Cc1ZMBUr4qF8TjGE=; b=qQFMkHeg/uHsWCFJam+8UmcfXehd/KGWtnv93tdWcGUtz7Dgn7eIDVa4y41x2w3tMR VnVKdpQV7XjMUxDC2XBTXqTX0kAM5EeZWdcZy29E+gAUOILObmX6G235NdTmJMQPlOnw TcDzYZ4H58QBT4iEeTKElRBQ2ST6H3cDfRbWYI/eFGsAOHI+41+nJXaNgBAbW4TvKQev h/7UNtX7hJLPQkQKjsvIpsaxrmzQ+T0odTQqWhmcFshC7shUTjE61FHpG3+VfjK2j4K9 l6XWdq9UmWW97i3sQUp7DHnE4aFUFeOFjotbH5j5rL4WZW26ghtdu3nYfss2FVjBu0Az sOzw== X-Received: by 10.107.158.70 with SMTP id h67mr14414014ioe.37.1418751890860; Tue, 16 Dec 2014 09:44:50 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Tue, 16 Dec 2014 09:44:30 -0800 (PST) In-Reply-To: <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> From: Ed Maste Date: Tue, 16 Dec 2014 12:44:30 -0500 X-Google-Sender-Auth: 4ofscdtP0zXp40l5yS37lDlv6v0 Message-ID: Subject: Re: Migration to dynamic libs for llvm and clang To: David Chisnall Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:44:51 -0000 On 16 December 2014 at 11:15, David Chisnall wrote: > > Upstream doesn't call it libclang (that's the name of the library with a = stable C ABI, which is why I'd like us not to confuse it with something wit= h a library with an unstable C++ API). They do produce a libLLVM.so from th= e LLVM builds and work is underway to have shared library builds for clang. Agreed. Even if there's no potential issue since it will be in /usr/lib/private it would be confusing. David's suggestion of libcfe sounds reasonable. >> That said, I agree with the general idea, but one of the first things >> we should decide is whether this will be optional or not. Having to >> maintain yet another WITH_CLANG_FOO option is burdensome... Fair enough, I'd definitely like to see fewer build-time knobs over time, not more. > I agree. I'd quite like to see performance numbers for the compiler. I = think I saw about a 10% overhead for buildworld last time I tried, but that= was a couple of years ago. Ok. I will put this together in a branch and we can compare results and decide which way to go when we have actual numbers. From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 17:47:02 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14057228; Tue, 16 Dec 2014 17:47:02 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC55A22F; Tue, 16 Dec 2014 17:47:01 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id rp18so13468298iec.11 for ; Tue, 16 Dec 2014 09:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lyWjrbCaiHn0uTXYA/pwGQu3C4X19J8O0a8b11uYpeI=; b=WVryVSIWbzqWRo6M2m40z43J9tD1gKB69jFc/RIUAexItTmmRKJjFgb8nG3cME90kA +5Rzj1QCvoPRfv+iDJgYRpgctYTmcGYSpixztPvIE/OZXB7T4IBvhtM2OX9SOaIeXbzR M41AuUs2EIJTGaZUnuFPwhqNM6v5X4w6qBKR5/ZfrOVYi2JWbfCed/sRvfuIAmtJ9hzY MGGFlpUf/WRIblnpIvucRKSt7KHU/Q29gT2my1qMvQr2pKZA5DLxPQVZTLDeDYVt3OHj 1ynhAWoXkN/TPNSfi9MfI4LpfsZW94mabnI+nJoMJsFQpGlXXRWNpxmkTCNKRYe25BjK mW2Q== X-Received: by 10.107.5.7 with SMTP id 7mr16290803iof.1.1418752021189; Tue, 16 Dec 2014 09:47:01 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Tue, 16 Dec 2014 09:46:40 -0800 (PST) In-Reply-To: <4E3A3DA8-209C-43E1-83D4-928823CCBF04@bsdimp.com> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> <4E3A3DA8-209C-43E1-83D4-928823CCBF04@bsdimp.com> From: Ed Maste Date: Tue, 16 Dec 2014 12:46:40 -0500 X-Google-Sender-Auth: PZ215_DjkJlldY-m8SGV1FhAo80 Message-ID: Subject: Re: Migration to dynamic libs for llvm and clang To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:47:02 -0000 On 16 December 2014 at 12:39, Warner Losh wrote: > > We should defer testing until after that import :) Indeed. I have an early WIP patch in a local branch, but any new work before 3.5.x lands will be wasted, so it will be in the new year that I'll have something to start testing. From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 17:54:19 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F3B7370 for ; Tue, 16 Dec 2014 17:54:19 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21A3D33C for ; Tue, 16 Dec 2014 17:54:19 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so14517947pab.16 for ; Tue, 16 Dec 2014 09:54:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ATpPqOROuOHfF6UjwzhY++CAzUELrX3O1JLGt57SKiU=; b=bZ2EsGyFgivLnJ8xIku8ShlPX8t9HyO5+lyEKWgMXO5oNEb+4C07Ij6R0fNzAMo0eH RTynS1/SLrpwbraeTgcZ0wiBkAhdoRleqDv0yBU1qPI/gRVQ80MlFuqYEimujYZP2eAJ 1j4QHZ0dWGINYtkb4zTVcnqAGwuECcRvC2FZPJmmxrMdbWWYSntwL12vtV0ARO0qdhly uNAoU272wDyuQRsEC2JGZGbn3gvoZLtYh9Xc0WZXXnWMP1Gl1cbpTlS776Mbdyvj7OHH jJNgjxO6E9H6FTvf/6dd6+6C2tC69r2BGaOox/gi79vFLYZ8NJQgjKpUdgJvTgZjODfM KQNA== X-Gm-Message-State: ALoCoQnryznH9pfgF5pqF7Ze2VuvDI+pQYhwB6ag2rKUyAF/1E1EdtLCXmYxRMDtoVMxogLFv6Qb X-Received: by 10.68.200.68 with SMTP id jq4mr25627647pbc.30.1418752458639; Tue, 16 Dec 2014 09:54:18 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id a13sm1572967pdm.44.2014.12.16.09.54.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 09:54:18 -0800 (PST) Sender: Warner Losh Subject: Re: Migration to dynamic libs for llvm and clang Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3D19435D-6238-441E-84E7-92213129B96A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Tue, 16 Dec 2014 10:54:15 -0700 Message-Id: <15A17E31-22CA-4680-869B-3B7AC1E49741@bsdimp.com> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> To: Ed Maste X-Mailer: Apple Mail (2.1993) Cc: Dimitry Andric , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:54:19 -0000 --Apple-Mail=_3D19435D-6238-441E-84E7-92213129B96A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 16, 2014, at 10:44 AM, Ed Maste wrote: >=20 > Fair enough, I'd definitely like to see fewer build-time knobs over > time, not more. Until we stop using build-time knobs to control what=E2=80=99s in the = final image as a poor man=E2=80=99s packaging scheme, I expect the number of knobs = to continue to grow. In this case, however, it should be covered under the existing knobs though (or we should eliminate the knob :). Warner --Apple-Mail=_3D19435D-6238-441E-84E7-92213129B96A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkHHHAAoJEGwc0Sh9sBEAlMgQAIls+vw6/DzThjXZXQmH3h4D HL5EAxOiXVcnCHm0H5HHtTM1Gu5OBasUea4PIFCorS2uJMv/XFsydwM+4WzaEK+c 8dJEo3sTS0zMG+KulitlPq8Fltk8IkEC+EQj2/uurFMO32/s2RB9s3Bx2+YvDfMF LKTGDClPmYPeoiwzO3qF82ZiAtihyWIt2Ef2W0Q6p1kA4HmX0Hz2/6HYStvZIf7C QXW0lrEjm/kD84xhjQbF71WTGoHSrVnqeLAcD3w5Tqr7HnqPlJHmEIQHEQI2iJRv zg8ERCKag/vq0AY3c6Vp00mQSFtugGHXx3DH01XbEqy7UErLar9L5UUcACMCsYCP k4KXXGUrQ6+ooDuV7sGJaI1aGOvNuvwsdHUrru7qryXEOrcvdaSciP1xIm/rBcRS r4qvA/8zeksjrc8bVfRgf4/hZuqL5TEGH7GNlGS66z4Jn4wxWDP8yncL5HQaa8jz 40FeaANBgiLiviuoK+dH6RqYgLmfJRNzkAFaUp/O9tkU72PzJ/+dC3sMzUr5jIhU pDJW2O+/KkS9UCVbvVwjaW4lgvPtn61Vh58jZbPjghwc98m+yKTJBn9Y0yB/eTBd ihzAZ8XHJm8SEZhnOcUsTYFFUIbHtiRF6VRwUoApPehFJcFidWJC2+Oki5LvUgbd CPuOCc4sK8CbePeIWqUw =xel+ -----END PGP SIGNATURE----- --Apple-Mail=_3D19435D-6238-441E-84E7-92213129B96A-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 19:01:42 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AC6E790; Tue, 16 Dec 2014 19:01:42 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45038C4E; Tue, 16 Dec 2014 19:01:42 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::949f:2cd4:f2b0:7a2d] (unknown [IPv6:2001:7b8:3a7:0:949f:2cd4:f2b0:7a2d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 29A3AB80A; Tue, 16 Dec 2014 20:01:37 +0100 (CET) Subject: Re: Migration to dynamic libs for llvm and clang Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3975A253-942B-4B98-8796-4149E6A1AC31"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: <15A17E31-22CA-4680-869B-3B7AC1E49741@bsdimp.com> Date: Tue, 16 Dec 2014 20:01:21 +0100 Message-Id: <6D28CE1D-B94D-4E5E-B2DC-96C47E6C63BF@FreeBSD.org> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> <15A17E31-22CA-4680-869B-3B7AC1E49741@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:01:42 -0000 --Apple-Mail=_3975A253-942B-4B98-8796-4149E6A1AC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 16 Dec 2014, at 18:54, Warner Losh wrote: >=20 >> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote: >>=20 >> Fair enough, I'd definitely like to see fewer build-time knobs over >> time, not more. >=20 > Until we stop using build-time knobs to control what=E2=80=99s in the = final image > as a poor man=E2=80=99s packaging scheme, I expect the number of knobs = to > continue to grow. How does a packaging scheme solve the problem of not compiling in dependencies, or linking everything static? You cannot pre-build all possible combinations of selectable options. As for knobs that just say "build foo" or "don't build bar", those would indeed be fine for a packaging system, as long as packages aren't too dependent on each other. -Dimitry --Apple-Mail=_3975A253-942B-4B98-8796-4149E6A1AC31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSQgY8ACgkQsF6jCi4glqMzcACfegfej1GQoK8rTzNeheYWNftK pgUAoIgdp28rTaTRvxHs8rKx4qPopLzS =1KaN -----END PGP SIGNATURE----- --Apple-Mail=_3975A253-942B-4B98-8796-4149E6A1AC31-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 19:36:30 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1CA1E9; Tue, 16 Dec 2014 19:36:30 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2227A9C; Tue, 16 Dec 2014 19:36:29 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::949f:2cd4:f2b0:7a2d] (unknown [IPv6:2001:7b8:3a7:0:949f:2cd4:f2b0:7a2d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 810F7B80A; Tue, 16 Dec 2014 20:36:25 +0100 (CET) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> Date: Tue, 16 Dec 2014 20:36:14 +0100 Message-Id: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> To: FreeBSD-Current X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:36:30 -0000 --Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Nov 2014, at 22:03, Dimitry Andric wrote: >=20 > We're working on updating llvm, clang and lldb to 3.5.0 in head. This > is quite a big update again, and any help with testing is appreciated. >=20 > To try this out, ensure you have good backups or snapshots, then build > world and kernel from the projects/clang350-import branch [1]. Please > use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. * PowerPC64 should mostly work, thanks to Justin Hibbits. * PowerPC32 might start working soon; it really needs some backporting of fixes to clang 3.4.1, which is now in head, so there is an easier upgrade path for PowerPC users. * Sparc64 still does not work, and I don't see any quick solutions to it for now. It should probably stay with gcc. * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. Lastly, to clear things up about the requirements for this branch (and thus for head, in a while); to build it, you need to have: * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or gcc >=3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D 4.8. So from any earlier standard 10.x or 11.x installation, you should be good, unless you explicitly disabled clang or libc++. In that case, you must build and install both of those first. On a 9.x installation, you will have clang by default, but not libc++, so libc++ should be built and installed first, before attempting to build the clang350-import branch. On 8.x an earlier, you need to upgrade to at least 9.x first, follow the previous instruction. As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while (roughly a month), but this will cause upgrades from 9.x to 10.x to start requiring the build of libc++, as described above. I don't think we can merge clang 3.5.x to 9.x, unless clang becomes the default compiler there (but that is very unlikely). -Dimitry [1] svn://svn.freebsd.org/base/projects/clang350-import [2] = https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn.html#svn-mi= rrors [3] = http://pb2.nyi.freebsd.org/build.html?mastername=3Dhead-amd64-PR195480-def= ault&build=3D2014-12-12_23h17m02s [4] https://svnweb.freebsd.org/changeset/ports/374780 --Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSQibcACgkQsF6jCi4glqMLqACdFS2s3k6N5P/wyb7iIfxuLpn5 2CoAn1K6tH3+OtZZc+K5NncA4dYaTE52 =Tg7o -----END PGP SIGNATURE----- --Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 19:47:21 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C4B275D for ; Tue, 16 Dec 2014 19:47:21 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 673251E8 for ; Tue, 16 Dec 2014 19:47:21 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id lf10so14120225pab.33 for ; Tue, 16 Dec 2014 11:47:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=FR4TwBX1LXu+dpLNSkJjrMsR1IJ2ySB3lZccKF8K1Lc=; b=jEIqAliz5LPiYHicqnovCAPwy4KcyQCru5/MP3tN+wOZIOn5MZh4oupApYSBwyP/mp ejG9kPpW5KASSoCMxOMUD3QiRMPaIL6mankf+2aRoKFMKqxszdkkYMJkhsTVa6U8km52 xYPlA/9hF19YMbp7hPfafCMl+YaGgZ3D/3AHco6MuERRAPfQaqUB52KZQnvxAQJbuJHs QWbH0v7bZ+gB1AOCn7mqj/GghN8nef6taX+LvEjZZCUgZhahFtv72BfC//G+nKJiVNFD P9KcyyJQLW2JoIuo0kCmFC+SXcyl7kktIxvwTn2NnXtsdaYsoicoxJuGVxA66T/+R5UK fJQQ== X-Gm-Message-State: ALoCoQlc8R3Y3/gzttuDD736guWzPLIjeDeK9kLSaF1NwV+GcecFDX1Zab6MyMyyCpI8IngowR5O X-Received: by 10.68.57.144 with SMTP id i16mr63328124pbq.86.1418759240139; Tue, 16 Dec 2014 11:47:20 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id ug6sm1796241pab.7.2014.12.16.11.47.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 11:47:19 -0800 (PST) Sender: Warner Losh Subject: Re: Migration to dynamic libs for llvm and clang Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A5ED19A7-AC5E-440E-8907-8DE594C8A531"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <6D28CE1D-B94D-4E5E-B2DC-96C47E6C63BF@FreeBSD.org> Date: Tue, 16 Dec 2014 12:47:16 -0700 Message-Id: <098F3C6B-6DB4-472F-9CA0-D12BE5E37A19@bsdimp.com> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> <15A17E31-22CA-4680-869B-3B7AC1E49741@bsdimp.com> <6D28CE1D-B94D-4E5E-B2DC-96C47E6C63BF@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:47:21 -0000 --Apple-Mail=_A5ED19A7-AC5E-440E-8907-8DE594C8A531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 16, 2014, at 12:01 PM, Dimitry Andric wrote: >=20 > On 16 Dec 2014, at 18:54, Warner Losh wrote: >>=20 >>> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote: >>>=20 >>> Fair enough, I'd definitely like to see fewer build-time knobs over >>> time, not more. >>=20 >> Until we stop using build-time knobs to control what=E2=80=99s in the = final image >> as a poor man=E2=80=99s packaging scheme, I expect the number of = knobs to >> continue to grow. >=20 > How does a packaging scheme solve the problem of not compiling in > dependencies, or linking everything static? You cannot pre-build all > possible combinations of selectable options. >=20 > As for knobs that just say "build foo" or "don't build bar", those = would > indeed be fine for a packaging system, as long as packages aren't too > dependent on each other. Right now we mix build options for building things or not (e.g. = WITH_SENDMAIL) with build options for things like this (WITH_SHARED_TOOLCHAIN). The = number of the former is increasing all the time (with a big increase when = Ngie=E2=80=99s work hits the tree). So in many senses, it is an orthogonal issue. My comment was more to Ed=E2=80=99s notion that these numbers will be dropping any time = soon. packing the base is actually a hard problem because the phrase =E2=80=9Cas= long as packages aren=E2=80=99t dependent on each other=E2=80=9D turns out to = not be the case as much as we might like. The base is fairly interdependent of all that = since we have it as one big ball of stuff right now. Most of the issues revolve = around dependence on the libraries and such. With patience and diligence, I = think we can package the base, but it isn=E2=80=99t going to be a trivial slam = dunk if it is going to be useful. Warner --Apple-Mail=_A5ED19A7-AC5E-440E-8907-8DE594C8A531 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkIxFAAoJEGwc0Sh9sBEAxzQP/2o98z/7Y9Tlc3ZrxHBxHU+X ij1svutS4QQV210j3JYAvKEgWBQambnAg1rO2uFhg48zbZd+Zf8SFe/l0+Tf7oGm aCE2/bONVJrGesR10DkHWXfx50Z9dqIfzapZQJ+z6//NHMO7bSYhFd1XFUQB9xIG WQfpJAX3BPu74reIsfHmT4R32BRlVdSY+4LX8AjLqtDSCTDib96pnDj6EwjFl79e NoA39WXG2C/eg6OZQyDX0q29nVqLpZNEh2o+WL+H1cOU48KE0ezotAtr4nt/Kwrl 2U9s6WP+QZkXv9Bd6XKz4h4DEdlz3pVmlg2F4qbz0pAUjPbGaltRQl2tFBFwcqcQ 9Jxapy27tDV0tIX0J29ZrTLT6Hn41FOeXDH9OeRa0ZIiElXMXUaRssm6yLr4B8II KpCUJ1cXxefNfasfyyZKxudG4efIvDpsyhkqwY1sWHnY9xi/YcYGZZ2HJj0/aJxA y25preqXFwUQr0/yYEg98WIGMsWEQPB8QY8XA7tNGNJWWzsN8gWxRdaYSd0zpMa7 vXPNsyNmPx9DntHFhT8/iYRvFr9jmg1y1aGffxClkx7yQfODPuweWRKlkWK/If/u g+tlBlKcl06yXf1SSeXtVzkVQ+SAtjYpQGk6nTryT6WGQOj3KNSfZo+lxNQ5Wqow MhS8C8Pz0cJFhL6FDUM7 =wTKG -----END PGP SIGNATURE----- --Apple-Mail=_A5ED19A7-AC5E-440E-8907-8DE594C8A531-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 19:55:37 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A0AAA24; Tue, 16 Dec 2014 19:55:37 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F01A735A; Tue, 16 Dec 2014 19:55:36 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id hn15so7689536igb.3 for ; Tue, 16 Dec 2014 11:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=3tFqeSRKnIcL3dHDkGwKVhkpE2L5QH/PIamDdz3eHCo=; b=BNIl01lRBAGVucs7Q5oi5UCkfIukSGfi4XR4RbR/g++jHseuU/JyXq5/E0og3T5TBa Y/yC2hWirGksMXR4QJaMaAfTkQD1gwzb376pPygaZdw0iNoHUZ8ylCRr3GNowbUDq7zu BeVv4wuUV9S60CfEF8G4EnY9vdDYju2YjvzPZkpiflYc1kt7vqwo6ql0P/1RucLGEKyF K0VY8ZjCzLvr4XE5qRljDPOFdBIjvQoL08Ud5eLrAsJE6A7apcEfyizCsh197CfNWjMx TSjeGDHFgEPVTsxvktlUTY5njOCPZxHAArYnQLvBYmxVlN4mAGni/INb0IoZum/SbkMH 3RdQ== X-Received: by 10.107.6.34 with SMTP id 34mr35334542iog.88.1418759736542; Tue, 16 Dec 2014 11:55:36 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Tue, 16 Dec 2014 11:55:16 -0800 (PST) In-Reply-To: <098F3C6B-6DB4-472F-9CA0-D12BE5E37A19@bsdimp.com> References: <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> <15A17E31-22CA-4680-869B-3B7AC1E49741@bsdimp.com> <6D28CE1D-B94D-4E5E-B2DC-96C47E6C63BF@FreeBSD.org> <098F3C6B-6DB4-472F-9CA0-D12BE5E37A19@bsdimp.com> From: Ed Maste Date: Tue, 16 Dec 2014 14:55:16 -0500 X-Google-Sender-Auth: XBKEr4fnYX59WqC0GusK5wuzcx0 Message-ID: Subject: Re: Migration to dynamic libs for llvm and clang To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:55:37 -0000 On 16 December 2014 at 14:47, Warner Losh wrote: > > My comment was > more to Ed=E2=80=99s notion that these numbers will be dropping any time = soon. To be clear, I don't expect we'll be dropping knobs soon. We should keep that as a goal to aim for. From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 21:45:53 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 56BB3D43; Tue, 16 Dec 2014 21:45:53 +0000 (UTC) Message-ID: <5490A810.7040002@FreeBSD.org> Date: Tue, 16 Dec 2014 16:45:52 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dimitry Andric , FreeBSD-Current Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:45:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/16/2014 14:36, Dimitry Andric wrote: > * The second exp-run had much better results: the failure with the > highest number of dependencies is devel/mingw32-gcc, but this > seems to be due to a problem with makeinfo, not clang. The next > highest on the list is java/openjdk6, for which ports r374780 [4] > was very recently committed. Unfortunately, r374780 was not enough. Instead, I just turned off "-Werror" for now (r374824). https://svnweb.freebsd.org/changeset/ports/374824 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUkKgGAAoJEHyflib82/FGGtAH/jyK3fVhWeXlgID5MKov0+vq 34BwE98ppJWreu4LdkXGqCUZeciyMmcw4ROfEPo6IthIxcHsRleh+O+BnmA5wFce gMczWBO1R+uEzcSH75UhyaVJVMKy8BJ2vRU2s90GANUnMhcMvNjN0Y89+8PdCHWF zaR8oy/GlVpJ13RTbyeaMf8K0T6MyQp58VQYP1gmlhjafEjVOLO9IVZyLWVx/nsI +DtjLj1DdNrPKrV1jrVRmZ+bJqOLaLgL4FUV/vruSduA1U8E1BZgnklXqRPowXqN jmFbLYE4kiygcEmUnpVbLQeB2EWXbQq7g4pijh90qDrhCSX1rUN3gz2DxY/Mub4= =reYk -----END PGP SIGNATURE----- From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 22:44:24 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB370D5C for ; Tue, 16 Dec 2014 22:44:24 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F368DD0 for ; Tue, 16 Dec 2014 22:44:24 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBGMiOuD019143 for ; Tue, 16 Dec 2014 22:44:24 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBGMiO7O019142; Tue, 16 Dec 2014 22:44:24 GMT (envelope-from root) Date: Tue, 16 Dec 2014 22:44:24 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Request, 3 lines] D1327: Do not strip all when stripping an explicit symbol Message-ID: X-Priority: 3 Thread-Topic: D1327: Do not strip all when stripping an explicit symbol X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MDY2NGYwOTg3ZWI5MTEzOGVkN2E5ZGIxZWVm X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:44:24 -0000 emaste created this revision. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY When asked to strip a specific symbol (-N) strip still defaulted to STRIP_ALL. In this case binutils defaults to stripping nothing (other than the requested symbol(s), of course), which makes a lot more sense. PR 196038 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196038 TEST PLAN - reduced test case from PR - build ffmpeg port REVISION DETAIL https://reviews.freebsd.org/D1327 AFFECTED FILES contrib/elftoolchain/elfcopy/main.c To: emaste Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 22:44:40 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC0D6D7F for ; Tue, 16 Dec 2014 22:44:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EDA3DD2 for ; Tue, 16 Dec 2014 22:44:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBGMierY019251 for ; Tue, 16 Dec 2014 22:44:40 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBGMieDG019250; Tue, 16 Dec 2014 22:44:40 GMT (envelope-from root) Date: Tue, 16 Dec 2014 22:44:40 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Updated] D1327: Do not strip all when stripping an explicit symbol Message-ID: <36b471337552c5d2859ec4c64ece8895@localhost.localdomain> X-Priority: 3 Thread-Topic: D1327: Do not strip all when stripping an explicit symbol X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MDY2NGYwOTg3ZWI5MTEzOGVkN2E5ZGIxZWVmIFSQtdg= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:44:40 -0000 emaste updated the summary for this revision. REVISION DETAIL https://reviews.freebsd.org/D1327 To: emaste Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 16 22:50:47 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C49CDE94 for ; Tue, 16 Dec 2014 22:50:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A55A1EA2 for ; Tue, 16 Dec 2014 22:50:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBGMolXC026277 for ; Tue, 16 Dec 2014 22:50:47 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBGMolZX026276; Tue, 16 Dec 2014 22:50:47 GMT (envelope-from root) Date: Tue, 16 Dec 2014 22:50:47 +0000 To: freebsd-toolchain@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Accepted] D1327: Do not strip all when stripping an explicit symbol Message-ID: <5c2ba7fff6ee55390547c4a10aacaa9f@localhost.localdomain> X-Priority: 3 Thread-Topic: D1327: Do not strip all when stripping an explicit symbol X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MDY2NGYwOTg3ZWI5MTEzOGVkN2E5ZGIxZWVmIFSQt0c= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:50:47 -0000 imp added a subscriber: imp. imp accepted this revision. imp added a reviewer: imp. imp added a comment. This revision is now accepted and ready to land. Looks good to me. REVISION DETAIL https://reviews.freebsd.org/D1327 To: emaste, imp Cc: imp, freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Wed Dec 17 14:46:56 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40CECEE for ; Wed, 17 Dec 2014 14:46:56 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 207D583A for ; Wed, 17 Dec 2014 14:46:56 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBHEktag099228 for ; Wed, 17 Dec 2014 14:46:55 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBHEkt5a099227; Wed, 17 Dec 2014 14:46:55 GMT (envelope-from root) Date: Wed, 17 Dec 2014 14:46:55 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Closed] D1327: Do not strip all when stripping an explicit symbol Message-ID: <43656f53d1bc0a6665b3b5843fcfd701@localhost.localdomain> X-Priority: 3 Thread-Topic: D1327: Do not strip all when stripping an explicit symbol X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MDY2NGYwOTg3ZWI5MTEzOGVkN2E5ZGIxZWVmIFSRl18= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:46:56 -0000 emaste closed this revision. emaste updated this revision to Diff 2778. emaste added a comment. Closed by commit rS275862 (authored by @emaste). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D1327?vs=2767&id=2778#toc REVISION DETAIL https://reviews.freebsd.org/D1327 AFFECTED FILES head/contrib/elftoolchain/elfcopy/main.c To: emaste, imp Cc: imp, freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 18 14:47:41 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1F32180 for ; Thu, 18 Dec 2014 14:47:41 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6493524EE for ; Thu, 18 Dec 2014 14:47:41 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so1509449pab.26 for ; Thu, 18 Dec 2014 06:47:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=p5IpbZglrLI1dIIJpyXpYFXl0CH/aGonP2IaKLPKrB4=; b=NyNMsXCo8WYF0XiKlm2C830Yt5yg9pBrHCLCUTRUcLBCkp5ZZnZvQc3VC4zxxmqU6f eym+EDjvdONUrHZr0Mn/a1stLVdYvK5J56F6mbAnfYLFU/d5eyoAYdqfoxGDka+X/Kfu CGM9DsgIyeQU+O1lhBF5HtRO7ziA+o4lY+pYcm0E1OEK36jw7ywP8IIXAipnBkZC7oZQ rYbMn25zfTouNILy6NBaHSkyC/bovr74/wjTypH1ScFLGoHruZC5F7AZzeeMNSRoDE7e oMAk/BtyCdFE/d821vrwluFyxCrRHbVGem5oy2TFN6L66mL3lcWPgEZnYcKmNtfBMzu0 bMGA== X-Gm-Message-State: ALoCoQnsCZ2vwN9A2xdEAdqFCNhquy0CbC+Q70f3mDP+ZXw8YFWs16+VOvuIPJM/imKkG34xoqxE X-Received: by 10.68.69.109 with SMTP id d13mr3975826pbu.57.1418914055686; Thu, 18 Dec 2014 06:47:35 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id t9sm6970859pbs.75.2014.12.18.06.47.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 06:47:34 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Date: Thu, 18 Dec 2014 07:47:31 -0700 Message-Id: References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 14:47:41 -0000 --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is excellent news Dimitry! > On Dec 16, 2014, at 12:36 PM, Dimitry Andric wrote: >=20 > On 28 Nov 2014, at 22:03, Dimitry Andric wrote: >>=20 >> We're working on updating llvm, clang and lldb to 3.5.0 in head. = This >> is quite a big update again, and any help with testing is = appreciated. >>=20 >> To try this out, ensure you have good backups or snapshots, then = build >> world and kernel from the projects/clang350-import branch [1]. = Please >> use a Subversion mirror [2], if you are able to. >=20 > Here are some updates about the status of the 3.5.0 import. >=20 > * i386 and amd64 have been tested through make universe, and = everything > should compile and run. > * Little-endian ARM builds should now compile and run, thanks to = Andrew > Turner for putting in lots of work. > * Big-endian ARM is apparently supposed to work, but I'm not sure if > Andrew managed to test it on real hardware. I know Andrew doesn=E2=80=99t have the right arm gear to do this test, = and emulation environments that run FreeBSD have had poor big-endian support for arm. > * PowerPC64 should mostly work, thanks to Justin Hibbits. > * PowerPC32 might start working soon; it really needs some backporting > of fixes to clang 3.4.1, which is now in head, so there is an easier > upgrade path for PowerPC users. > * Sparc64 still does not work, and I don't see any quick solutions to = it > for now. It should probably stay with gcc. > * Mips will only have a chance with the upcoming clang 3.6.0, but that > is way too late for this import. It will probably require external > toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. > * Another ports exp-run was done [3], after fixing the problem with > lang/gcc, which lead to many skipped dependent ports. > * The second exp-run had much better results: the failure with the > highest number of dependencies is devel/mingw32-gcc, but this seems > to be due to a problem with makeinfo, not clang. The next highest on > the list is java/openjdk6, for which ports r374780 [4] was very > recently committed. Will users of our stable branch have code similar to the code that = caused problems? One warning flag about your upgrade to the stable branch would be if there=E2=80=99s a significant number of user-written = programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there=E2=80=99s a good chance we won=E2=80=99t find them until users hit = them and start to complain (by which point it is likely too late). Could you post a = summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. > I would really like to merge this branch to head in about a week, > pending portmgr approvall; I don't expect the base system (outside of > llvm/clang) to need any further updates. I think there=E2=80=99s good reason to do this, but we should chat about = the build issues below before doing it. They are minor, but an important detail. I=E2=80=99ll see if I can find a few minutes to pull the branch = and send patches. > Lastly, to clear things up about the requirements for this branch (and > thus for head, in a while); to build it, you need to have: > * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) > * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >=20 > So from any earlier standard 10.x or 11.x installation, you should be > good, unless you explicitly disabled clang or libc++. In that case, > you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get = the word out a little better. > On a 9.x installation, you will have clang by default, but not libc++, > so libc++ should be built and installed first, before attempting to > build the clang350-import branch. Can you make sure that the UPDATING entry you are writing for this contains explicit instructions. > On 8.x an earlier, you need to upgrade to at least 9.x first, follow > the previous instruction. We should remove building on 8 support then, unless there external toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). > As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while > (roughly a month), but this will cause upgrades from 9.x to 10.x to > start requiring the build of libc++, as described above. I don't = think > we can merge clang 3.5.x to 9.x, unless clang becomes the default > compiler there (but that is very unlikely). Let=E2=80=99s see how it goes, and what the upgrade issues wind up being before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers on = stable branches traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly identical to prior releases than gcc was, it might not have the same = issues associated with it. Warner --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkukEAAoJEGwc0Sh9sBEAT0kP/Rnez5JSvAwYw80kxMc/Ui1P rvW0Nq7D3sMYxXHY13Frt0+yT/7JEZpXMRGFGHijwaKd/iSgUT2W04BQAYHkjWWj Z2cq/mFLrKtcS8puBpDGC9hGkZ6jeB06k6N82mu+HrbrMtNxb7Rl9MAeaPyZl0vb dmKVFmSDSnlNCSSE6sJygmexT4JKcP+2Bv8U/C4htCsKwnYzbroUJVhmhNwm6NHp Tgloml0B3IVdd3rY91uW6Ie1He1px96uoFnFS7IeHWsC2CkVKrpdOwoLXJdk8ofr /uyKvOCng7pmGmoNVE6/h0RdPGGatjHwdHgF2V1in4I2XNWmavMq8Js3+ipPAB0t ox4TMQqGWnOIAsGJiyAboPbrC4gTj3DpTVJp4SyROYMWMXtp8w26fOktzwErmHEq ghxR8GO8ypq5lhpURuzyprkn4rp++PHeLN5soDmFYjx8k39FXB8iWkrhFjiyaNh4 kaa1GWXTxuaDOMiDRLjgluo7LstAn5jUir0HX/CnPgycEFw5yCxEia7dTqHj0Jmx uGdx8a+ZnSptbuSjfytT0BH9TLRj2wYdGmwGNA12KrgYOuBTCZqEaOpdYvE0KN2W 4tFdAfr13vUzcUk0W6bD1uVFUn2myKvy7gxPD7C4+NyJ5ZUTLHKiwyeFn3O7KzeL QDFb8Gg5HEyaoGI9gSpf =k3ZX -----END PGP SIGNATURE----- --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 18 15:13:09 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7795D0C; Thu, 18 Dec 2014 15:13:09 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 717D828B4; Thu, 18 Dec 2014 15:13:09 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so929735igb.4; Thu, 18 Dec 2014 07:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=SkeiuxlMllPCCedntig5tW7cJGjhzmTBLKixwx6qWcc=; b=dN5XEi3ih8xv6I8SAAT9yQosD9rBp9cf76oq41+YJv9ZCV6lRSs1uyD7RrbzAGSm8/ I3RidRgR5r5vg2v6UejBb0f0jHCAZpicqClAqFlcIVPo7B/xPQpRCyzz97d3hFwKNuDQ flqWtjBYrRnX6kY7p1ViSiOT/t788hoIH3SA6msb1WY1uPUTRD5MJNRdVXQ6xyMFlVfc K+wkZPrYLgecBbzob+GEarMnUOtFuvu1+m/uRA7QSjwQSQblUNNb2ZS7iRB2u77VgaoW 8umF5Dz0bpuee6UxLTii9eb4xJ1KYaSlI0ATpdjf/COlXad98LX3z+e9JrmKGhky6hvZ EbrQ== X-Received: by 10.43.79.2 with SMTP id zo2mr2390943icb.78.1418915588894; Thu, 18 Dec 2014 07:13:08 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Thu, 18 Dec 2014 07:12:47 -0800 (PST) From: Ed Maste Date: Thu, 18 Dec 2014 10:12:47 -0500 X-Google-Sender-Auth: 3Mwqy4DKS4CyZF0wjpFhoG3z2DM Message-ID: Subject: Call for testing: elftoolchain tools To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 15:13:09 -0000 We have a rather outdated version of binutils in the base system. As part of a project to update our toolchain I've started working on using some of the tools from the elftoolchain project. There is now a build knob to enable the use of the following tools: * addr2line * elfcopy (strip) * nm * size * strings The knob (in /etc/src.conf) is: WITH_ELFTOOLCHAIN_TOOLS=yes The binutils version is still used for as, ld, objcopy, objdump and readelf; future projects will handle these. The option is being tested in ports exp-runs on amd64 and i386, and has had basic sanity testing on arm64 and mips64. I'm interested in test reports across a variety of hardware architectures and use cases. If everything works as expected you should see no difference -- the tools should be drop-in replacements. -Ed From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 18 15:32:10 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 759443DF; Thu, 18 Dec 2014 15:32:10 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CB042B45; Thu, 18 Dec 2014 15:32:09 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id D3A0F1C71B0; Thu, 18 Dec 2014 10:23:29 -0500 (EST) Received: from [127.0.0.1] (vnat004.nandomedia.com [166.108.31.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id B8FCB1A9118; Thu, 18 Dec 2014 10:23:28 -0500 (EST) Message-ID: <5492F16F.5010606@mail.lifanov.com> Date: Thu, 18 Dec 2014 10:23:27 -0500 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ed Maste , FreeBSD Current Subject: Re: Call for testing: elftoolchain tools References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 15:32:10 -0000 On 12/18/14 10:12, Ed Maste wrote: > We have a rather outdated version of binutils in the base system. As > part of a project to update our toolchain I've started working on > using some of the tools from the elftoolchain project. There is now a > build knob to enable the use of the following tools: > > * addr2line > * elfcopy (strip) > * nm > * size > * strings > > The knob (in /etc/src.conf) is: > WITH_ELFTOOLCHAIN_TOOLS=yes > > The binutils version is still used for as, ld, objcopy, objdump and > readelf; future projects will handle these. > > The option is being tested in ports exp-runs on amd64 and i386, and > has had basic sanity testing on arm64 and mips64. > > I'm interested in test reports across a variety of hardware > architectures and use cases. If everything works as expected you > should see no difference -- the tools should be drop-in replacements. > > -Ed > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I was running WITH_ELFTOOLCHAIN_TOOLS for a few days on head/amd64 and clang350-import/amd64. Things build and work as before. I'm not seeing any behavior differences. - Nikolai Lifanov From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 18 19:01:26 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1C503A5; Thu, 18 Dec 2014 19:01:26 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45FA72E5A; Thu, 18 Dec 2014 19:01:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::74f6:f05:5a8d:a897] (unknown [IPv6:2001:7b8:3a7:0:74f6:f05:5a8d:a897]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A2B7BB80A; Thu, 18 Dec 2014 20:01:20 +0100 (CET) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: Date: Thu, 18 Dec 2014 20:01:09 +0100 Message-Id: <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> To: Warner Losh X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 19:01:26 -0000 --Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 18 Dec 2014, at 15:47, Warner Losh wrote: ... >> * Mips will only have a chance with the upcoming clang 3.6.0, but = that >> is way too late for this import. It will probably require external >> toolchain support to get it working. >=20 > For native builds yes. For cross builds, clang 3.6 can be built on an > x86 host. Yes, and it could even be one of the ports, if that is easier to use. > * Another ports exp-run was done [3], after fixing the problem with >> lang/gcc, which lead to many skipped dependent ports. >> * The second exp-run had much better results: the failure with the >> highest number of dependencies is devel/mingw32-gcc, but this seems >> to be due to a problem with makeinfo, not clang. The next highest on >> the list is java/openjdk6, for which ports r374780 [4] was very >> recently committed. >=20 > Will users of our stable branch have code similar to the code that = caused > problems? I'm not sure which code you are referring to here, the openjdk6 code? The code itself is basically fine, but for reasons unknown to me, the port is compiled with -Werror (which is not the case for the other openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings for shaky C++ constructions, these appear during the openjdk6 build, but they are easily suppressed, if upstream does not fix them, or does not care to fix them. I already sent Jung-uk an alternative fix for openjkd6, similar to the one used for www/squid, where warnings are suppressed based on the COMPILER_VERSION variable provided the ports infrastructure. In my opinion it would still be easier to just to turn off -Werror for any third-party code, if we don't feel like modifying it (with all the risks involved). > One warning flag about your upgrade to the stable branch > would be if there=E2=80=99s a significant number of user-written = programs that > suddenly become uncompilable with the new clang using the environment > that they have today. We know of some items that are issues, so = careful > attention here is needed. Unless we go proactively looking for these, > there=E2=80=99s a good chance we won=E2=80=99t find them until users = hit them and start > to complain (by which point it is likely too late). Could you post a = summary > of the issues that ports have hit and the fixes necessary? We may need > to have that in the release notes and/or UPDATING file to help prepare > our users for the bumps and give them solutions over them. The base system is already completely free of warnings, as far as I know of, so no action is needed there. For ports, the number of failures introduced by new warnings are quite small, as far as I can see, and mostly for ports that are compiled with -Werror. The most encountered new warnings are, off the top of my head: -Wabsolute-value This warns in two cases, for both C and C++: * When the code is trying to take the absolute value of an unsigned quantity, which is effectively a no-op, and almost never what was intended. The code should be fixed, if at all possible. * When the code is trying to take the absolute value, but the called abs() variant is of the wrong type, which may lead to truncation. If the warning is turned off, better make sure any truncation does not lead to unwanted side-effects. -Wtautological-undefined-compare and -Wundefined-bool-conversion These warn when C++ code is trying to compare 'this' against NULL, while 'this' should never be NULL in well-defined C++ code. However, there is some legacy (pre C++11) code out there, which actively abuses this feature, which was less strictly defined in previous C++ versions. Squid does this, and apparently openjdk too. The warning can be turned off for C++98 and earlier, but compiling the code in C++11 mode might result in unexpected behavior, for example the unreachable parts of the program could be optimized away. > I would really like to merge this branch to head in about a week, >> pending portmgr approvall; I don't expect the base system (outside of >> llvm/clang) to need any further updates. >=20 > I think there=E2=80=99s good reason to do this, but we should chat = about the > build issues below before doing it. They are minor, but an important > detail. I=E2=80=99ll see if I can find a few minutes to pull the = branch and send > patches. >=20 >> Lastly, to clear things up about the requirements for this branch = (and >> thus for head, in a while); to build it, you need to have: >> * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >>> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) >> * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >>=20 >> So from any earlier standard 10.x or 11.x installation, you should be >> good, unless you explicitly disabled clang or libc++. In that case, >> you must build and install both of those first. >=20 > This is true only on i386, amd64, and arm hosts. Given that some = people > do try to do weird things, tightening up how you present this will get = the > word out a little better. >=20 >> On a 9.x installation, you will have clang by default, but not = libc++, >> so libc++ should be built and installed first, before attempting to >> build the clang350-import branch. >=20 > Can you make sure that the UPDATING entry you are writing for this > contains explicit instructions. I'm quite bad at writing UPDATING entries, so any help there is much appreciated. :-) > On 8.x an earlier, you need to upgrade to at least 9.x first, follow >> the previous instruction. >=20 > We should remove building on 8 support then, unless there external > toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). The problem with 8.x is that it still has the old binutils 2.15, and neither clang nor libc++. It would really require some externally supplied parts. Maybe this could be done with ports, but I'm not sure how long ports still supports the 8.x branch? >> As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while >> (roughly a month), but this will cause upgrades from 9.x to 10.x to >> start requiring the build of libc++, as described above. I don't = think >> we can merge clang 3.5.x to 9.x, unless clang becomes the default >> compiler there (but that is very unlikely). >=20 > Let=E2=80=99s see how it goes, and what the upgrade issues wind up = being > before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers on = stable branches > traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly > identical to prior releases than gcc was, it might not have the same = issues > associated with it. We don't really use llvm or clang's own ABI for anything at the moment, just the resulting compiler executable, which is actually one big binary (and it is even statically linked, by default). The code output by clang 3.4.1 or 3.5.0 is not different in any "ABI" sense of the word. Of course it will be different in absolute sense, since optimizations were improved, and so on. The only real issue is how to bootstrap the compiler itself, since it requires working C++11 support. In 10.x, we provide that by default, but not in earlier releases. -Dimitry --Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSTJH0ACgkQsF6jCi4glqOyzwCfUxIAeT19Ct+Sar04C72noiC3 SwcAoONLkGO04a0C7/Y9oxfTfhidmjs3 =SWHs -----END PGP SIGNATURE----- --Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 18 21:29:53 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8650FD4E for ; Thu, 18 Dec 2014 21:29:53 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FE3F282A for ; Thu, 18 Dec 2014 21:29:53 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id ft15so2169666pdb.8 for ; Thu, 18 Dec 2014 13:29:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=8xMcoKdxkZ0OSGQ9A3Uh7Kv6tWCSy2ty83F8QmuIcGY=; b=Lw9WV/XkStb0Jg8sMNBKL7UlBk3oWoQJyZmcYliUA4V+NvmsXVHQ0ymS57977VQmAB kAIwFMO/0o5Lm8MMoV+pI54HsMBinWWLEKxc34PEwEZakW82V+SBFhYjSz2AWUpMf1V/ hzUjfxgtglDeGNDp+x/R1R7J7ZH209iTxT7TYjfx498ExEsXIOma7vl7fZDCMIzpP2OF 2d4AcCDA66XFIqihX8L9kLF0Wn+wGHH1TVJpnjF3xsDd+wgH0Gv1l91o6djBk2j+k73o 3G6BGkzK45IRr4UJGPsg7CZJNlNuIK69emc5IvQ/ylaY0m02oU2AEReXn1c4hN+eH6je VXvQ== X-Gm-Message-State: ALoCoQmxXKw35JnnB8xipdeudiINAJp1Xe6bVcoNrGXB/hnVDzHfqTzcylOaH9dAiBl1wdnydCn2 X-Received: by 10.70.27.225 with SMTP id w1mr7073622pdg.40.1418938192638; Thu, 18 Dec 2014 13:29:52 -0800 (PST) Received: from [10.64.25.114] ([69.53.236.236]) by mx.google.com with ESMTPSA id eo4sm7558138pbb.87.2014.12.18.13.29.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 13:29:51 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> Date: Thu, 18 Dec 2014 14:29:49 -0700 Message-Id: <8C5EFF7C-9CA0-43A4-89A3-C6BFF518E83E@bsdimp.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 21:29:53 -0000 --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 18, 2014, at 12:01 PM, Dimitry Andric wrote: >=20 > On 18 Dec 2014, at 15:47, Warner Losh wrote: > ... >>> * Mips will only have a chance with the upcoming clang 3.6.0, but = that >>> is way too late for this import. It will probably require external >>> toolchain support to get it working. >>=20 >> For native builds yes. For cross builds, clang 3.6 can be built on an >> x86 host. >=20 > Yes, and it could even be one of the ports, if that is easier to use. >=20 >=20 >> * Another ports exp-run was done [3], after fixing the problem with >>> lang/gcc, which lead to many skipped dependent ports. >>> * The second exp-run had much better results: the failure with the >>> highest number of dependencies is devel/mingw32-gcc, but this seems >>> to be due to a problem with makeinfo, not clang. The next highest = on >>> the list is java/openjdk6, for which ports r374780 [4] was very >>> recently committed. >>=20 >> Will users of our stable branch have code similar to the code that = caused >> problems? >=20 > I'm not sure which code you are referring to here, the openjdk6 code? > The code itself is basically fine, but for reasons unknown to me, the > port is compiled with -Werror (which is not the case for the other > openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings > for shaky C++ constructions, these appear during the openjdk6 build, = but > they are easily suppressed, if upstream does not fix them, or does not > care to fix them. I meant =E2=80=9Csimilar code to what=E2=80=99s causing problems=E2=80=9D = with the build run in their code they build on FreeBSD. If it is a few new warnings for obscure = things, we can advice to the release notes about what to avoid and how to = mitigate things. > I already sent Jung-uk an alternative fix for openjkd6, similar to the > one used for www/squid, where warnings are suppressed based on the > COMPILER_VERSION variable provided the ports infrastructure. In my > opinion it would still be easier to just to turn off -Werror for any > third-party code, if we don't feel like modifying it (with all the = risks > involved). Yea, we can sort out the code in src and ports. I=E2=80=99m more worried = about what to tell our users that may be compiling their own code that we = don=E2=80=99t control. If these new warnings are ubiquitous, then that could be a = problem for adoption (since many shops mandate -Werror as much as possible, and to comply with that mandate would require additional resources when = trying to upgrade). If there are a few, then we could just document them and = move on. >> One warning flag about your upgrade to the stable branch >> would be if there=E2=80=99s a significant number of user-written = programs that >> suddenly become uncompilable with the new clang using the environment >> that they have today. We know of some items that are issues, so = careful >> attention here is needed. Unless we go proactively looking for these, >> there=E2=80=99s a good chance we won=E2=80=99t find them until users = hit them and start >> to complain (by which point it is likely too late). Could you post a = summary >> of the issues that ports have hit and the fixes necessary? We may = need >> to have that in the release notes and/or UPDATING file to help = prepare >> our users for the bumps and give them solutions over them. >=20 > The base system is already completely free of warnings, as far as I = know > of, so no action is needed there. For ports, the number of failures > introduced by new warnings are quite small, as far as I can see, and > mostly for ports that are compiled with -Werror. Yea, I wasn=E2=80=99t too worried about this aspect of things. > The most encountered new warnings are, off the top of my head: >=20 > -Wabsolute-value >=20 > This warns in two cases, for both C and C++: > * When the code is trying to take the absolute value of an unsigned > quantity, which is effectively a no-op, and almost never what was > intended. The code should be fixed, if at all possible. > * When the code is trying to take the absolute value, but the called > abs() variant is of the wrong type, which may lead to truncation. > If the warning is turned off, better make sure any truncation does > not lead to unwanted side-effects. >=20 > -Wtautological-undefined-compare and > -Wundefined-bool-conversion >=20 > These warn when C++ code is trying to compare 'this' against NULL, = while > 'this' should never be NULL in well-defined C++ code. However, there = is > some legacy (pre C++11) code out there, which actively abuses this > feature, which was less strictly defined in previous C++ versions. >=20 > Squid does this, and apparently openjdk too. The warning can be = turned > off for C++98 and earlier, but compiling the code in C++11 mode might > result in unexpected behavior, for example the unreachable parts of = the > program could be optimized away. This is the kind of information I was talking about. Do we have a = process to make sure this gets into the release notes? >> I would really like to merge this branch to head in about a week, >>> pending portmgr approvall; I don't expect the base system (outside = of >>> llvm/clang) to need any further updates. >>=20 >> I think there=E2=80=99s good reason to do this, but we should chat = about the >> build issues below before doing it. They are minor, but an important >> detail. I=E2=80=99ll see if I can find a few minutes to pull the = branch and send >> patches. >>=20 >>> Lastly, to clear things up about the requirements for this branch = (and >>> thus for head, in a while); to build it, you need to have: >>> * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >>>> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) >>> * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >>>=20 >>> So from any earlier standard 10.x or 11.x installation, you should = be >>> good, unless you explicitly disabled clang or libc++. In that case, >>> you must build and install both of those first. >>=20 >> This is true only on i386, amd64, and arm hosts. Given that some = people >> do try to do weird things, tightening up how you present this will = get the >> word out a little better. >>=20 >>> On a 9.x installation, you will have clang by default, but not = libc++, >>> so libc++ should be built and installed first, before attempting to >>> build the clang350-import branch. >>=20 >> Can you make sure that the UPDATING entry you are writing for this >> contains explicit instructions. >=20 > I'm quite bad at writing UPDATING entries, so any help there is much > appreciated. :-) I=E2=80=99m happy to help with this, but I work best from a rough draft = ... >> On 8.x an earlier, you need to upgrade to at least 9.x first, follow >>> the previous instruction. >>=20 >> We should remove building on 8 support then, unless there external >> toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, = etc). >=20 > The problem with 8.x is that it still has the old binutils 2.15, and > neither clang nor libc++. It would really require some externally > supplied parts. Maybe this could be done with ports, but I'm not sure > how long ports still supports the 8.x branch? If we can=E2=80=99t bootstrap from an 8.x system and have it work, we = need to remove support for doing that from Makefile.inc1 and friends. If we = think we can still support it with the external tool chain stuff, or with the = =E2=80=98end goal=E2=80=99 for the external toolchain stuff, we should leave it in. = At this point, I think it would be best to add a .warning for 8.x saying this isn=E2=80=99= t supported without an external toolchain, and then a month out from the branch = point we can decide what to do. 8.x is supported through the summer, iirc, on ports. Right now, for example, we say if the host is < 8.0 then we = don=E2=80=99t support it. I=E2=80=99ll add something that says if the host is < = 9 then bootstrapping clang won=E2=80=99t work, but I won=E2=80=99t make it an error just yet = and send it to you for your branch. >>> As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while >>> (roughly a month), but this will cause upgrades from 9.x to 10.x to >>> start requiring the build of libc++, as described above. I don't = think >>> we can merge clang 3.5.x to 9.x, unless clang becomes the default >>> compiler there (but that is very unlikely). >>=20 >> Let=E2=80=99s see how it goes, and what the upgrade issues wind up = being >> before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers = on stable branches >> traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly >> identical to prior releases than gcc was, it might not have the same = issues >> associated with it. >=20 > We don't really use llvm or clang's own ABI for anything at the = moment, > just the resulting compiler executable, which is actually one big = binary > (and it is even statically linked, by default). Right, this isn=E2=80=99t what I=E2=80=99m worried about... > The code output by clang 3.4.1 or 3.5.0 is not different in any "ABI" > sense of the word. Of course it will be different in absolute sense, > since optimizations were improved, and so on. This is what I=E2=80=99m worried about given our past experiences with = updating compilers. If we believe there=E2=80=99s no issues here, we can tick = that box but it was traumatic enough the last time we tried this (admittedly with gcc) that I have to ask. Similar representations were made, though it turned out people forgot to ask =E2=80=9Cincluding C++=E2=80=9D until = people noticed that it failed in some cases and started asking=E2=80=A6 > The only real issue is how to bootstrap the compiler itself, since it > requires working C++11 support. In 10.x, we provide that by default, > but not in earlier releases. Yea, that=E2=80=99s something we can document with release notes. Cool! Thanks for taking the time to address my concerns. Warner --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUk0dNAAoJEGwc0Sh9sBEAmUwP/jomM0zYSx9Pn+idgoLi8od8 l/e3bSMwuQcG8jZK+O7XkH+HFPMeDHRJUbFnr3TbnkHhxJIra5x7dOr0BArwzSDW vA1XwBNYcYsUQcgIlLNZ6KLOWmJoyTc8MVoEZPveVqVIyQwCHxHockm1Sl/jdkay fQMtnjES9ToBtpp4tqEFz/kb2hD4V1jJi90CXBdnAvzb2sFAQGZroSpIATo1n+0I XCUo8v1D/28T5xpapD4KUO3hqLc/UOeuozcEi/gBltix5e8xOCkVHyg9pGkiwJ9h 44J2o7k75LWPMZ9T52sCPFtc0F8RAKLcw1pSjRwfN9chCLirx1qnOBJwUmRH863Z X3Im4zDstU5rJhD4Dejsbals308oqyvjyLwS1nvdhReRbXajrj8O3F0UazWTB3cl oOEByTILaN5yrNdw5Y0WF8rPhP4cNQTKAyPv6BFolWW8fbPe8N573DbLbaZpQuX+ 41ppg/dkuV0FEQSVXFL70qZpKA1dRvnE2gBVxNaY5UTLr2urMDpR1ncvmqEVB65y E4qtgCPA9bSx0FPbajPHH8cO2KfK7T/DpHZlTmFLQ8ELWaPu1Vb6sY6mFTJ/es6V y5F4UzwwLsPZdxL/zedpK5J3DtU2tz+mM404267T7lRNOIFupGpZM4iSS0owXcQ+ yoxSQXZj5E1Z+/SMvK+S =ZvMz -----END PGP SIGNATURE----- --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 19 00:12:43 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 893CDC88; Fri, 19 Dec 2014 00:12:43 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4097A2255; Fri, 19 Dec 2014 00:12:42 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sBJ0CfUV078928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 16:12:42 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sBJ0CfC9078927; Thu, 18 Dec 2014 16:12:41 -0800 (PST) (envelope-from jmg) Date: Thu, 18 Dec 2014 16:12:41 -0800 From: John-Mark Gurney To: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <20141219001241.GW25139@funkthat.com> Mail-Followup-To: Warner Losh , Dimitry Andric , FreeBSD ARM , FreeBSD-Current , portmgr@freebsd.org, FreeBSD ports , FreeBSD toolchain References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 18 Dec 2014 16:12:42 -0800 (PST) Cc: FreeBSD-Current , Dimitry Andric , FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 00:12:43 -0000 Warner Losh wrote this message on Thu, Dec 18, 2014 at 07:47 -0700: > This is excellent news Dimitry! > > > On Dec 16, 2014, at 12:36 PM, Dimitry Andric wrote: > > > > On 28 Nov 2014, at 22:03, Dimitry Andric wrote: > >> > >> We're working on updating llvm, clang and lldb to 3.5.0 in head. This > >> is quite a big update again, and any help with testing is appreciated. > >> > >> To try this out, ensure you have good backups or snapshots, then build > >> world and kernel from the projects/clang350-import branch [1]. Please > >> use a Subversion mirror [2], if you are able to. > > > > Here are some updates about the status of the 3.5.0 import. > > > > * i386 and amd64 have been tested through make universe, and everything > > should compile and run. > > * Little-endian ARM builds should now compile and run, thanks to Andrew > > Turner for putting in lots of work. > > * Big-endian ARM is apparently supposed to work, but I'm not sure if > > Andrew managed to test it on real hardware. > > I know Andrew doesn???t have the right arm gear to do this test, and emulation > environments that run FreeBSD have had poor big-endian support for arm. I have a board that I plan to test on shortly... If Andrew would like, I know Jim Thompson has a standing offer to send board(s) to people who will test it... He provided me w/ the board I will be testing on soon... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 19 04:57:27 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACB0A39C for ; Fri, 19 Dec 2014 04:57:27 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D07621DE for ; Fri, 19 Dec 2014 04:57:27 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id r10so421911pdi.23 for ; Thu, 18 Dec 2014 20:57:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:subject:date:message-id :cc:to:mime-version; bh=93l8+vdo/ktywdOT145l/LsgjPBPdSXYBfwumGg9U4w=; b=IS+pz3GfZX30afy0ijHRSDp4PafK/EflW2WjtcdaUO4pfO+9FZRoSEepyfg2Ic2RXc pzDbBIwZKA84zsxqEl2l5lrndzsaLHqegmbq1KRkSEwCsbboiOe2NC3jz3N2x6AjN12u BQYOsPkmPZQu8naCW0I4LzswW24m5i2hndlfgOlen84JDcUDYUhIIDfxzId6C6SMOn9U k7Cn/OfEc8oFSpyU8EHDqyYdXcCXuv/sNTIu/IXefCDhACneLws1aIHfkIcWWcOdy7Vg zCAiLm/wXxMZK0i0ullD4/DjSJ9OpRYhr470u6QDNzw7gjVNfr2IaLHZY17gHPlO4O2C Zudg== X-Gm-Message-State: ALoCoQk4vzhQqtyh8oMfSCx3g7WWq8xVMCPx383Ego/hkBmcaA7FetlA5xnkdnJ1tQ/3DrTa+UXO X-Received: by 10.66.142.166 with SMTP id rx6mr9454846pab.33.1418965046427; Thu, 18 Dec 2014 20:57:26 -0800 (PST) Received: from [10.64.25.114] ([69.53.236.236]) by mx.google.com with ESMTPSA id j10sm8170696pdr.92.2014.12.18.20.57.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 20:57:25 -0800 (PST) Sender: Warner Losh From: Warner Losh X-Pgp-Agent: GPGMail 2.5b3 Content-Type: multipart/signed; boundary="Apple-Mail=_B2B497C4-5FBB-4D39-973B-88831A85AA8F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: armeb build of clang350-import Date: Thu, 18 Dec 2014 21:57:22 -0700 Message-Id: <36DE57D9-9FE4-44C6-9440-EED79C4322C7@bsdimp.com> To: John-Mark Gurney , Dimitry Andric Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Cc: FreeBSD toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 04:57:27 -0000 --Apple-Mail=_B2B497C4-5FBB-4D39-973B-88831A85AA8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thought I=E2=80=99d try to build armeb on clang350-import branch on my = ad64 host, and found it failed to build because of a dependency on a = machine include that doesn=E2=80=99t exist yet. % make buildworld TARGET=3Darm TARGET_ARCH=3Darmeb = -DWITHOUT_GCC{,_BOOTSTRAP} -DWITH_CLANG{,_BOOTSTRAP} ... =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) (cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make = -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.b= in/cc/cc_tools/Makefile = MFILE=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../= ../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/..= /../../contrib/gcc tm.h) TARGET_CPU_DEFAULT=3D"" HEADERS=3D"options.h dbxelf.h elfos-undef.h = elfos.h freebsd-native.h freebsd-spec.h freebsd.h arm/elf.h arm/aout.h = arm/bpabi.h arm/freebsd.h arm/arm.h defaults.h" DEFINES=3D"" /bin/sh = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/mkconfig.sh tm.h echo '#define EXTRA_MODES_FILE "arm/arm-modes.def"' >> tm.h (cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make = -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.b= in/cc/cc_tools/Makefile = MFILE=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../= ../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/..= /../../contrib/gcc tconfig.h) TARGET_CPU_DEFAULT=3D"" HEADERS=3D"auto-host.h ansidecl.h" = DEFINES=3D"USED_FOR_TARGET" /bin/sh = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/mkconfig.sh tconfig.h (cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make = -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.b= in/cc/cc_tools/Makefile = MFILE=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../= ../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/..= /../../contrib/gcc options.h) LC_ALL=3DC awk -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/opt-gather.awk = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/c.opt = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/common.opt = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/config/arm/arm.opt > optionlist LC_ALL=3DC awk -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/opt-functions.awk -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/opth-gen.awk < optionlist > options.h (cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make = -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.b= in/cc/cc_tools/Makefile = MFILE=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../= ../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/..= /../../contrib/gcc unwind.h) ln -sf = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/config/arm/unwind-arm.h unwind.h (cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make = -f = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.b= in/cc/cc_tools/Makefile = MFILE=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../= ../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/..= /../../contrib/gcc gthr-default.h) ln -sf = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/gthr-posix.h gthr-default.h cc -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2 = -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../= contrib/gcclibs/include = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../= contrib/gcc/config = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../= contrib/gcc -I. = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr= .bin/cc/cc_tools -Dinhibit_libc -fno-inline -std=3Dgnu99 = -fheinous-gnu-extensions -Qunused-arguments -fvisibility=3Dhidden = -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 -DElfW=3D__ElfN -o = unwind-arm.o = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/config/arm/unwind-arm.c cc -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2 = -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../= contrib/gcclibs/include = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../= contrib/gcc/config = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../= contrib/gcc -I. = -I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr= .bin/cc/cc_tools -Dinhibit_libc -fno-inline -std=3Dgnu99 = -fheinous-gnu-extensions -Qunused-arguments -fvisibility=3Dhidden = -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 -DElfW=3D__ElfN -o = libunwind.o = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/config/arm/libunwind.S = /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../co= ntrib/gcc/config/arm/libunwind.S:29:10: fatal error: = 'machine/acle-compat.h' file not found #include ^ 1 error generated. *** Error code 1 --Apple-Mail=_B2B497C4-5FBB-4D39-973B-88831A85AA8F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUk7AzAAoJEGwc0Sh9sBEA9fkP/14QywqnvSAjZYKlkAScSHYI y7Xwe54KmeFIfq6BBecjJOaqf2FalIxtin88tw83JIVv/QMGStRYPpn47JZ5Wzkn it+5g6dwCN+lNrSFZCx7HcvUTjdXsG43ZjLi0nksRlnt4mejNcNJa3DAp1mxVHqj 7pDFwtsD+Bkbetq+9FT7ArN4bGsqnGWrPJwa4976ttDRdhemqMru/IwV36p6aWNT hnPHSQReSGyq0SwYRk5ajG1z0MhJFvc0UxtxqmROqJ7CGUdR6PUYPSSlZSf2up5b OGD2FTbwOwkPbghgiAcVoZFbMhHIse7ra6b0zpVgeinln65SXHBQke2yiGhU0VE0 X3iUoztM8nm8pEu4DymtGB6rokQNZIJUF58fW4Lys59ulv0krQke6E9KqWmLwZKz 6HkuKJbBpc5KIUxIXtuENykHZ3QQi6Tk1Q6fGFt3fqy1GR4sFjtpEvSRoPNzEEkg vxvpcyS6bO9JdOpD7TNIMD/fuhDz9Q2v6hdbhoRBwv9k8V2O5XSRo9dAeSm29FvS PQgIdakVrZ2jVXoJcghCRRQF6B8DNKBcodqXHuCVV+yn2inqxXvP2LWXUh/QCrDW 3PurTT37679bFNxuUmLmDgw6pERXFqe6wblzj0po1Bm3P43sHVuiq5YqvN9vlRAk 8RMj+oW2JSy92IlNPOTi =RT5k -----END PGP SIGNATURE----- --Apple-Mail=_B2B497C4-5FBB-4D39-973B-88831A85AA8F-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 19 05:42:33 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D96B2645; Fri, 19 Dec 2014 05:42:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8897329E5; Fri, 19 Dec 2014 05:42:32 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sBJ5gUMx002810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 21:42:31 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sBJ5gUSA002809; Thu, 18 Dec 2014 21:42:30 -0800 (PST) (envelope-from jmg) Date: Thu, 18 Dec 2014 21:42:30 -0800 From: John-Mark Gurney To: Dimitry Andric Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <20141219054230.GA1396@funkthat.com> Mail-Followup-To: Dimitry Andric , FreeBSD-Current , FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@freebsd.org References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 18 Dec 2014 21:42:31 -0800 (PST) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@freebsd.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 05:42:33 -0000 Dimitry Andric wrote this message on Tue, Dec 16, 2014 at 20:36 +0100: > * Big-endian ARM is apparently supposed to work, but I'm not sure if > Andrew managed to test it on real hardware. hmmm... I can't get it to compile... Maybe I'm missing something... I tried to do: # make buildworld TARGET_ARCH=3Darmeb WITH_BOOTSTRAP_CLANG=3D WITH_CLANG=3D= WITHOUT_GCC=3D WITHOUT_BOOTSTRAP_GCC=3D This is from an amd64 host, though it is a month or two out of date... But it ended w/: c++ -O -pipe -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/include -= I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/a/= src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. = -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include = -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MA= CROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armeb-gnueabi-fr= eebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"armeb-unknown-freebsd11.0\" -DDEFAULT_SY= SROOT=3D\"\" -fno-exceptions -fno-rtti -static -o clang cc1_main.o cc1as= _main.o driver.o /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/= clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/arm.armeb/a/src/= usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a = /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangdri= ver/libclangdriver.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../= lib/clang/libclangserialization/libclangserialization.a /usr/obj/arm.armeb/= a/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodege= n.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclan= gparse/libclangparse.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../.= ./lib/clang/libclangsema/libclangsema.a /usr/obj/arm.armeb/a/src/usr.bin/cl= ang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/a= rm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangedit/libclang= edit.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libc= langast/libclangast.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../..= /lib/clang/libclangbasic/libclangbasic.a /usr/obj/arm.armeb/a/src/usr.bin/c= lang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/arm.armeb/= a/src/usr.bin/clang/clang/../../../lib/clang/libllvmoption/libllvmoption.a = /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmlink= er/libllvmlinker.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../li= b/clang/libllvmirreader/libllvmirreader.a /usr/obj/arm.armeb/a/src/usr.bin/= clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/arm.armeb/a= /src/usr.bin/clang/clang/../../../lib/clang/libllvmvectorize/libllvmvectori= ze.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllv= minstrumentation/libllvminstrumentation.a /usr/obj/arm.armeb/a/src/usr.bin/= clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj= /arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/li= bllvmbitreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/= clang/libllvmasmparser/libllvmasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/= clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassemble= r.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvm= armcodegen/libllvmarmcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang= /../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/arm.= armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdesc/libllvmar= mdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/lib= llvmarminfo/libllvmarminfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/.= ./../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/ar= m.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdisassemble= r/libllvmmipsdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/..= /../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/arm.armeb= /a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmparser/libllvmm= ipsasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/cl= ang/libllvmmipsdesc/libllvmmipsdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clan= g/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/arm.a= rmeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinstprinter/li= bllvmmipsinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../.= ./lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/obj/arm.arme= b/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmparser/libl= lvmpowerpcasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../..= /lib/clang/libllvmpowerpcdesc/libllvmpowerpcdesc.a /usr/obj/arm.armeb/a/src= /usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcin= fo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllv= mpowerpcinstprinter/libllvmpowerpcinstprinter.a /usr/obj/arm.armeb/a/src/us= r.bin/clang/clang/../../../lib/clang/libllvmsparcdisassembler/libllvmsparcd= isassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/cla= ng/libllvmsparccodegen/libllvmsparccodegen.a /usr/obj/arm.armeb/a/src/usr.b= in/clang/clang/../../../lib/clang/libllvmsparcasmparser/libllvmsparcasmpars= er.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllv= msparcdesc/libllvmsparcdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/= ../../../lib/clang/libllvmsparcinfo/libllvmsparcinfo.a /usr/obj/arm.armeb/a= /src/usr.bin/clang/clang/../../../lib/clang/libllvmsparcinstprinter/libllvm= sparcinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../li= b/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/obj/arm.armeb/= a/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86= asmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang= /libllvmx86codegen/libllvmx86codegen.a /usr/obj/arm.armeb/a/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/= obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinte= r/libllvmasmprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../..= /lib/clang/libllvmmcparser/libllvmmcparser.a /usr/obj/arm.armeb/a/src/usr.b= in/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/obj/= arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmobjcarcopts/l= ibllvmobjcarcopts.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../l= ib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/obj/arm.armeb/a/src/usr= .bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a= /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmtra= nsformutils/libllvmtransformutils.a /usr/obj/arm.armeb/a/src/usr.bin/clang/= clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/obj/arm.armeb/a/src/u= sr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /us= r/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86desc= /libllvmx86desc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib= /clang/libllvmx86info/libllvmx86info.a /usr/obj/arm.armeb/a/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a /usr/obj/arm.arme= b/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86instprinter/libllv= mx86instprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib= /clang/libllvmmc/libllvmmc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/.= ./../../lib/clang/libllvmobject/libllvmobject.a /usr/obj/arm.armeb/a/src/us= r.bin/clang/clang/../../../lib/clang/libllvmx86utils/libllvmx86utils.a /usr= /obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/lib= llvmcore.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/= libllvmsupport/libllvmsupport.a -lncursesw /usr/obj/arm.armeb/a/src/tmp/usr/lib/crt1.o: In function `__start': crt1.c:(.text+0xb4): relocation truncated to fit: R_ARM_CALL against symbol= `atexit' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/= libc.a(atexit.o) crt1.c:(.text+0xbc): relocation truncated to fit: R_ARM_CALL against symbol= `_init_tls' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/l= ib/libc.a(tls.o) crt1.c:(.text+0xc4): relocation truncated to fit: R_ARM_CALL against symbol= `atexit' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/= libc.a(atexit.o) crt1.c:(.text+0x164): relocation truncated to fit: R_ARM_CALL against symbo= l `exit' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/l= ibc.a(exit.o) /usr/obj/arm.armeb/a/src/tmp/usr/lib/crt1.o: In function `finalizer': crt1.c:(.text+0x1d4): relocation truncated to fit: R_ARM_CALL against symbo= l `_fini' defined in .fini section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/= crti.o cc1_main.o: In function `__static_initialization_and_destruction_0(int, int= )': cc1_main.cpp:(.text+0xdc): relocation truncated to fit: R_ARM_CALL against = symbol `getenv' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/us= r/lib/libc.a(getenv.o) cc1_main.cpp:(.text+0x2c4): relocation truncated to fit: R_ARM_CALL against= symbol `std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)' defined in .t= ext._ZNSsC1EPKcRKSaIcE[_ZNSsC1EPKcRKSaIcE] section in /usr/obj/arm.armeb/a/= src/tmp/usr/lib/libstdc++.a(string-inst.o) cc1_main.cpp:(.text+0x374): relocation truncated to fit: R_ARM_JUMP24 again= st symbol `__gnu_cxx::__exchange_and_add(int volatile*, int)' defined in .t= ext._ZN9__gnu_cxx18__exchange_and_addEPVii section in /usr/obj/arm.armeb/a/= src/tmp/usr/lib/libstdc++.a(atomicity.o) cc1_main.cpp:(.text+0x388): relocation truncated to fit: R_ARM_JUMP24 again= st symbol `std::string::_Rep::_M_destroy(std::allocator const&)' defi= ned in .text._ZNSs4_Rep10_M_destroyERKSaIcE[_ZNSs4_Rep10_M_destroyERKSaIcE]= section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/libstdc++.a(string-inst.o) cc1_main.cpp:(.text+0x3a0): relocation truncated to fit: R_ARM_CALL against= symbol `std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)' defined in .t= ext._ZNSsC1EPKcRKSaIcE[_ZNSsC1EPKcRKSaIcE] section in /usr/obj/arm.armeb/a/= src/tmp/usr/lib/libstdc++.a(string-inst.o) cc1_main.cpp:(.text+0x44c): additional relocation overflows omitted from th= e output *** Error code 1 Stop. make[5]: stopped in /a/src/usr.bin/clang/clang *** Error code 1 Stop. make[4]: stopped in /a/src/usr.bin/clang *** Error code 1 Stop. make[3]: stopped in /a/src/usr.bin *** Error code 1 Stop. make[2]: stopped in /a/src *** Error code 1 Stop. make[1]: stopped in /a/src *** Error code 1 Stop. make: stopped in /a/src --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 19 15:31:54 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E5AFFC for ; Fri, 19 Dec 2014 15:31:54 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 524552D30 for ; Fri, 19 Dec 2014 15:31:54 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBJFVsoZ064621 for ; Fri, 19 Dec 2014 15:31:54 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBJFVsrX064620; Fri, 19 Dec 2014 15:31:54 GMT (envelope-from root) Date: Fri, 19 Dec 2014 15:31:54 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Request, 11 lines] D1341: Set up default shstrtab entries at initialization Message-ID: X-Priority: 3 Thread-Topic: D1341: Set up default shstrtab entries at initialization X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: Thread-Index: NzRmMDNlMzgzZGYyYjg5YjNiMzczNThiMzY0 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:31:54 -0000 emaste created this revision. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY If we use -R to remove all sections we still need a .shstrtab (which will itself be the only section entry). Do not wait until the addition of the first non-default entry to create the default ones. Elftoolchain ticket 463 https://sourceforge.net/p/elftoolchain/tickets/463/ TEST PLAN ``` touch empty.s make empty.o strip -o empty-stripped.o -R .text -R .data -R .bss -R .ARM.attributes -R .reginfo -R .gnu.attributes -R .MIPS.abiflags -R .pdr -R .xtensa.info empty.o readelf -S empty.o ``` REVISION DETAIL https://reviews.freebsd.org/D1341 AFFECTED FILES elfcopy/sections.c To: emaste Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 19 15:34:50 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DF5F14D for ; Fri, 19 Dec 2014 15:34:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F00F2D69 for ; Fri, 19 Dec 2014 15:34:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBJFYnrT066790 for ; Fri, 19 Dec 2014 15:34:49 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBJFYn13066789; Fri, 19 Dec 2014 15:34:49 GMT (envelope-from root) Date: Fri, 19 Dec 2014 15:34:49 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Updated] D1341: Set up default shstrtab entries at initialization Message-ID: X-Priority: 3 Thread-Topic: D1341: Set up default shstrtab entries at initialization X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzRmMDNlMzgzZGYyYjg5YjNiMzczNThiMzY0IFSURZk= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:34:50 -0000 emaste updated the test plan for this revision. REVISION DETAIL https://reviews.freebsd.org/D1341 To: emaste Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 19 20:19:40 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16C7CC98 for ; Fri, 19 Dec 2014 20:19:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E99AC21D3 for ; Fri, 19 Dec 2014 20:19:39 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBJKJdrd055406 for ; Fri, 19 Dec 2014 20:19:39 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBJKJdh2055405; Fri, 19 Dec 2014 20:19:39 GMT (envelope-from root) Date: Fri, 19 Dec 2014 20:19:39 +0000 To: freebsd-toolchain@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Accepted] D1341: Set up default shstrtab entries at initialization Message-ID: X-Priority: 3 Thread-Topic: D1341: Set up default shstrtab entries at initialization X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzRmMDNlMzgzZGYyYjg5YjNiMzczNThiMzY0IFSUiFs= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 20:19:40 -0000 imp added a subscriber: imp. imp accepted this revision. imp added a reviewer: imp. imp added a comment. This revision is now accepted and ready to land. I believe this is OK... REVISION DETAIL https://reviews.freebsd.org/D1341 To: emaste, imp Cc: imp, freebsd-toolchain