Re: clang options for load segments
On Tue, 2 Mar 2021 at 14:37, Paul Floyd wrote: > > I'll work on fixing it in Valgrind, but that is likely to be fair amount > of work. I guess that recent Clang+lld will produce the same PT_LOAD on Linux too, so it seems like this is definitely something Valgrind will need to handle. > No need to hold your breath. Concerning the FreeBSD port I've been > working on Valgrind on FreeBSD for about a year or so and now it's not > too far from working as well on FreeBSD as it does on Linux*. > > Either install the devel/valgrind-devel package (note: not > devel/valgrind) or even better build and install from my github repo > https://github.com/paulfloyd/freebsd_valgrind. I have a commit bit for > upstream Valgrind and am working on integrating FreeBSD support in the > 'official' Valgrind. This probably won't be in the next release, 3.17, > due soon, but I hope that it gets into the next one (3.17.1 or 3.18). > And I'm always on the lookout for any user feedback :-) . Thank you so much for this, I will be very happy to finally see FreeBSD support upstream. IMO we should look at removing devel/valgrind and replacing it with valgrind-devel, given the amount of not-upstream work that exists in both of them. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang options for load segments
On 3/2/21 7:31 PM, Dimitry Andric wrote: [snip - history of change] 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. :) I'll work on fixing it in Valgrind, but that is likely to be fair amount of work. No need to hold your breath. Concerning the FreeBSD port I've been working on Valgrind on FreeBSD for about a year or so and now it's not too far from working as well on FreeBSD as it does on Linux*. Either install the devel/valgrind-devel package (note: not devel/valgrind) or even better build and install from my github repo https://github.com/paulfloyd/freebsd_valgrind. I have a commit bit for upstream Valgrind and am working on integrating FreeBSD support in the 'official' Valgrind. This probably won't be in the next release, 3.17, due soon, but I hope that it gets into the next one (3.17.1 or 3.18). And I'm always on the lookout for any user feedback :-) . 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. This seems to do the job as a workaround, thanks. A+ Paul * rust, OMP, clang debuginfo and some signal issues being the exceptions that I'm aware of ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang options for load segments
On 19 Feb 2021, at 15:18, Paul Floyd wrote: > > 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. > > 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/e8710ef1fbe8109eaa36143654f325dd345f8a0133 ) commit e8710ef1fbe8109eaa36143654f325dd345f8a01 Author: Fangrui Song Date: Fri Mar 15 01:29:57 2019 + [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 signature.asc Description: Message signed with OpenPGP
