From owner-freebsd-stable@freebsd.org Thu May 17 11:03:27 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B6B8EE941D for ; Thu, 17 May 2018 11:03:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (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 893F27A0A0 for ; Thu, 17 May 2018 11:03:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3FB235362A; Thu, 17 May 2018 13:03:24 +0200 (CEST) From: Dimitry Andric Message-Id: <517DB772-5A49-415B-9D79-52E5AB60AF75@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_67266C6D-8DE6-4D64-A7F7-CDDF05687E0C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: uptime / w coredumping on RELENG11 (i386 only) Date: Thu, 17 May 2018 13:03:20 +0200 In-Reply-To: <9d2e0a4d-b2d7-315a-cc17-7965913aea39@heuristicsystems.com.au> Cc: Mike Tancsa , FreeBSD-STABLE Mailing List To: Dewayne Geraghty References: <990862af-7bee-0d4b-c01f-d7fc8e5b6cfe@sentex.net> <955d6681-0048-5e09-cca6-4691b05bf48f@sentex.net> <18E4C626-410B-417F-89F2-4F16074749A1@FreeBSD.org> <865dd1e1-b29e-7d5b-41a5-e23a07b2f981@sentex.net> <9d2e0a4d-b2d7-315a-cc17-7965913aea39@heuristicsystems.com.au> X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 11:03:27 -0000 --Apple-Mail=_67266C6D-8DE6-4D64-A7F7-CDDF05687E0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 May 2018, at 02:01, Dewayne Geraghty = wrote: >=20 > On 17/05/2018 7:17 AM, Dimitry Andric wrote: >> On 16 May 2018, at 15:54, Mike Tancsa wrote: >>> On 5/15/2018 2:31 PM, Dimitry Andric wrote: >>>> On 15 May 2018, at 20:22, Mike Tancsa wrote: >>>>>> Anyone else see this ? >>>> See . There is a fix coming up. >>> I tried the patch and did a full rebuild and it indeed fixed the = problem >>> for me. Is the bug potentially more wide spread that just libxo ? = Also >>> does it possibly affect amd64, just in a non obvious way ? >> Yes to both, at least theoretically. The problem is actually in >> elftoolchain's strip command, which can mess up the TLS section in an >> executable or shared library. When the dynamic linker loads such a = bad >> file, it will setup incorrect TLS data, which can lead to crashes. >>=20 >> In case of libxo.so.0, this appears to have been caused by clang 6 >> giving a slightly different ELF layout than clang 5. During = buildworld, >> libxo.so.0 is built with debugging information, which is later copied >> to a libxo.so.0.debug file, while it is removed from the original >> libxo.so.0 file. >>=20 >> Up to this point, everything is still fine with libxo.so.0, still, = but >> during installworld, the file is stripped *again*, by install -s = (this >> is something we should revisit because it seems no longer useful). = This >> second round of stripping messes up the TLS section. >>=20 >> -Dimitry >>=20 > Revisit? Perhaps, but it seems that its a regression against clang6 = over > clang5. Well, my argument is that as long as any compiler and linker spit out a valid ELF file, strip should not corrupt it. :) And for certain, running strip twice on the same file should never change it (except for maybe timestamp-related fields). > Looking at > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D333600 > its appears that the section flags are correctly applied now. When > 333600 enters 11.1Beta?, do you think the build/installation process > requires revision? No, it should be enough to fix strip. In the installworld stage, the copy of strip built during the cross-tools stage is used. What I meant with revisiting this, is that historically we've stripped executables and shared libraries during installworld, as those could optionally have been built with debug information. But since the introduction of /usr/lib/debug, this is no longer the case: effectively, everything is built *with* debug information, and this debug information is already stripped out and moved to separate files during the buildworld stage. Therefore, it is no longer necessary to strip those files again. > Its a little disappointing to hear that the stripping process breaks = the > output, if applied >1. And that was actually the bug. Note that this only happens for TLS segments, which are not used very often. That is probably the reason we never ran into problems before. -Dimitry --Apple-Mail=_67266C6D-8DE6-4D64-A7F7-CDDF05687E0C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWv1heAAKCRCwXqMKLiCW oytaAJ9Sb7CsyubeFGiuiEZx4xkG7uT4JgCfcC/xw38n6aqty8INLKwlEARs0YU= =oNrx -----END PGP SIGNATURE----- --Apple-Mail=_67266C6D-8DE6-4D64-A7F7-CDDF05687E0C--