From owner-freebsd-toolchain@freebsd.org Tue Mar 2 18:31:58 2021 Return-Path: Delivered-To: freebsd-toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A77D954B5BD for ; Tue, 2 Mar 2021 18:31:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dqm1p4DXcz4rsy for ; Tue, 2 Mar 2021 18:31:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9100B54B814; Tue, 2 Mar 2021 18:31:58 +0000 (UTC) Delivered-To: toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 90CBA54B813 for ; Tue, 2 Mar 2021 18:31:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dqm1p3hfHz4rsx; Tue, 2 Mar 2021 18:31:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 5DEB89006; Tue, 2 Mar 2021 18:31:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::4957:9a38:706b:37b] (unknown [IPv6:2001:470:7a58:0:4957:9a38:706b:37b]) (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 9D7F065C1E; Tue, 2 Mar 2021 19:31:56 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_B5C9CB36-EC83-4B0C-B720-CDCB056EC96E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: clang options for load segments From: Dimitry Andric In-Reply-To: Date: Tue, 2 Mar 2021 19:31:50 +0100 Cc: "toolchain@freebsd.org" Message-Id: <4D81BCDE-ECBC-49D8-BF17-38E334141FE0@FreeBSD.org> References: To: Paul Floyd X-Mailer: Apple Mail (2.3445.104.17) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Mar 2021 18:31:58 -0000 --Apple-Mail=_B5C9CB36-EC83-4B0C-B720-CDCB056EC96E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Feb 2021, at 15:18, Paul Floyd wrote: >=20 > A while back when I upgraded to FreeBSD 12.2 (and thus to clang 10) I = got quite a new category of errors with Valgrind. >=20 > The problem is that the clang 10 toolchain produces two RW LOAD = segments, for instance see below. Valgrind assumes > that there is only one, and ignores the second one which results in = false positives when reading PLTs. I've added a hack > to make it seem like there is just one such segment, but it isn't 100% = reliable - there's at least one issue when loading > shared libraries. This changed in lld 9.0.0, with upstream r356226 (aka = https://github.com/llvm/llvm-project/commit/e8710ef1fbe8109eaa36143654f325= dd345f8a0133 ) commit e8710ef1fbe8109eaa36143654f325dd345f8a01 Author: Fangrui Song Date: Fri Mar 15 01:29:57 2019 +0000 [ELF] Split RW PT_LOAD on the PT_GNU_RELRO boundary Summary: Based on Peter Collingbourne's suggestion in D56828. Before D56828: PT_LOAD(.data PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) = .bss) Old: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .data = .bss) New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) = PT_LOAD(.data. .bss) The new layout reflects the runtime memory mappings. By having two PT_LOAD segments, we can utilize the NOBITS part of = the first PT_LOAD and save bytes for .bss.rel.ro. .bss.rel.ro is currently small and only used by copy relocations of symbols in read-only segments, but it can be used for other purposes = in the future, e.g. if a relro section's statically relocated data is = all zeros, we can move it to .bss.rel.ro. Reviewers: espindola, ruiu, pcc Reviewed By: ruiu Subscribers: nemanjai, jvesely, nhaehnle, javed.absar, kbarton, = emaste, arichardson, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58892 llvm-svn: 356226 In other words, this is shuffling the segments around a bit to achieve a more optimal layout for relro. > I will carry on looking for a proper solution. In the meantime, are = there any flags to revert to the previous behaviour > and only generate a single RW LOAD segment? I think valgrind should be fixed to able to cope with additional segments, but I haven't seen valgrind working on FreeBSD for years now, so I am not going to hold my breath. :) That said, you can attempt to link your executables with -z norelro (or -Wl,-z,norelro via the compiler driver). If there is no PT_GNU_RELRO header, lld will not split the segments. And of course, you can link with lld 8.0 if all else fails. -Dimitry --Apple-Mail=_B5C9CB36-EC83-4B0C-B720-CDCB056EC96E 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYD6ElgAKCRCwXqMKLiCW o/EFAKDHHmZjrvZ653I0KGAbvt/q/nAI2wCg59JAXh4VBTShLCOIMLAl+Xprmjs= =FXEd -----END PGP SIGNATURE----- --Apple-Mail=_B5C9CB36-EC83-4B0C-B720-CDCB056EC96E--