Re: clang options for load segments
Hi Ed PT_LOAD, I'm fully in agreement, I need to fix this in Valgrind. Thank you so much for this, I will be very happy to finally see FreeBSD support upstream. Me too! 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. What I think would be best is that when 3.17 comes out, we move devel/valgrind to be based on that date and move valgrind-devel to 3.18 (if that is the next version). And when it is finally upstreamed, base the ports off the official sourceware git repo. A+ Paul ___ 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 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
clang options for load segments
Hi 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. 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? A+ Paul paulf> /usr/bin/readelf --segments bar_trivial Elf file type is EXEC (Executable file) Entry point 0x2018c0 There are 11 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align [snip] LOAD 0x0f80 0x00202f80 0x00202f80 0x0158 0x0158 RW 0x1000 LOAD 0x10d8 0x002040d8 0x002040d8 0x0090 0x00a8 RW 0x1000 [snip] Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.tag .dynsym .gnu.version .gnu.version_r .gnu.hash .hash .dynstr .rela.plt .rodata .eh_frame_hdr .eh_frame 03 .text .init .fini .plt 04 .ctors .dtors .jcr .dynamic 05 .data .got.plt .bss 06 .dynamic 07 .ctors .dtors .jcr .dynamic 08 .eh_frame_hdr 09 10 .note.tag ___ 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"
