Date: Tue, 2 Mar 2021 19:31:50 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Paul Floyd <pjfloyd@wanadoo.fr> Cc: "toolchain@freebsd.org" <toolchain@FreeBSD.org> Subject: Re: clang options for load segments Message-ID: <4D81BCDE-ECBC-49D8-BF17-38E334141FE0@FreeBSD.org> In-Reply-To: <fb3e3660-a6c0-c8ce-5055-624cde7ce95c@wanadoo.fr> References: <fb3e3660-a6c0-c8ce-5055-624cde7ce95c@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <pjfloyd@wanadoo.fr> 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 <maskray@google.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D81BCDE-ECBC-49D8-BF17-38E334141FE0>