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 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"
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"
Re: Getting started with clang debuginfo
> On 27 Jul 2020, at 17:39, Konstantin Belousov wrote: > > On Mon, Jul 27, 2020 at 10:37:53AM -0400, Mark Johnston wrote: >> On Mon, Jul 27, 2020 at 11:27:40AM +0200, Paul FLOYD wrote: >>> Hi >>> >>> I'm investigating some of the remaining issues with Valgrind on FreeBSD. >>> One of the two remaining major issues that I'm aware of is with Valgrind >>> reading dwarf debuginfo from clang compiled binaries. The problem isn't >>> too bad with clang 8 on FreeBSD 12.1. On 13-CURRENT with clang 10 things >>> are noticeably worse. For GCC built binaries I'm not aware of any issues. >>> >>> I'm not familiar (yet) with the debuginfo code in Valgrind. >>> >>> To get me going, does anyone have any pointers to >>> - documentation on clang debuginfo > Clang generates DWARF which is documented by the DWARF standard(s), > available at http://dwarfstd.org/ The site seems to be down ATM. From what I’ve read, DWARF is somewhat flexible and allows for vendor extensions. For instance I’ve already seen DW_AT_GNU_all_call_sites and DW_GNU_all_tail_call_sites. > >>> - any info on differences wrt GCC (I have seen that GCC does have some >>> debuginfo extensions) > Gcc also generates DWARF. It is up to the compiler to interpret the standard > and provide compliant metadata according to it. > > But I would expect that the practical difference or troubles in parsing > the compiler' output is due to different versions of the used standard. > Both gcc and clang allow to specify which level of standard should be > used, see the description of the -gdwarf- switch. > > Different versions of the same compiler might default to different > version of DWARF as well. > No, I don’t think that is the problem. Valgrind can read DWARF up to version 4 (not 5). If it encounters a version it does not know about it says so directly ==1602== Command: ./leak_dwarf5 ==1602== --1602-- WARNING: Serious error when reading debug info --1602-- When reading debug info from /usr/home/paulf/scratch/vg_examples/leak_dwarf5: --1602-- Ignoring non-Dwarf2/3/4 block in .debug_info --1602-- WARNING: Serious error when reading debug info --1602-- When reading debug info from /usr/home/paulf/scratch/vg_examples/leak_dwarf5: --1602-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 ==1602== So I suspect that this is a question of dialect rather than version. 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: Getting started with clang debuginfo
> On 27 Jul 2020, at 16:37, Mark Johnston wrote: > > On Mon, Jul 27, 2020 at 11:27:40AM +0200, Paul FLOYD wrote: >> Hi >> >> I'm investigating some of the remaining issues with Valgrind on FreeBSD. One >> of the two remaining major issues that I'm aware of is with Valgrind reading >> dwarf debuginfo from clang compiled binaries. The problem isn't too bad >> with clang 8 on FreeBSD 12.1. On 13-CURRENT with clang 10 things are >> noticeably worse. For GCC built binaries I'm not aware of any issues. >> >> I'm not familiar (yet) with the debuginfo code in Valgrind. >> >> To get me going, does anyone have any pointers to >> - documentation on clang debuginfo >> - any info on differences wrt GCC (I have seen that GCC does have some >> debuginfo extensions) >> - any tools that would be useful like ascii dumps > > Are you asking about tools to dump DWARF info? I've used dwarfdump > (from ports) quite a bit in the past. readelf -w is similar and > available in the base system. Hi Mark Yes, I’m trying to start working out where there are differences Clang 8 vs clang 10 vs just about any GCC I’d already seen readelf, but I hadn’t installed dwarfdump. I just had a look at one example, there’s a bit less info in the clang generated file, but otherwise it looks OK. Next I’ll try comparing a problem clang 10 binary with a clang 8 one. 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"
Getting started with clang debuginfo
Hi I'm investigating some of the remaining issues with Valgrind on FreeBSD. One of the two remaining major issues that I'm aware of is with Valgrind reading dwarf debuginfo from clang compiled binaries. The problem isn't too bad with clang 8 on FreeBSD 12.1. On 13-CURRENT with clang 10 things are noticeably worse. For GCC built binaries I'm not aware of any issues. I'm not familiar (yet) with the debuginfo code in Valgrind. To get me going, does anyone have any pointers to - documentation on clang debuginfo - any info on differences wrt GCC (I have seen that GCC does have some debuginfo extensions) - any tools that would be useful like ascii dumps 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: x86 process memory map
> It is the stack grow area and the guard, combined. Read the mmap(2), in> > particular explanation of MAP_STACK and MAP_GUARD. I see from the mmap man page that this appeared in FreeBSD 11.1. Do you know where the size of the stack guard gets defined? I tried searching on google for stuff like 'stack MAP_GUARD size' but didn't find anything. (I need this to fix setting up the client stack on Valgrind x86, which is currently broken) 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: x86 process memory map
> It is the stack grow area and the guard, combined. Read the mmap(2), in > particular explanation of MAP_STACK and MAP_GUARD. OK, thanks very much. I will go and read the man page. 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"
x86 process memory map
When I run procstat on a small 32bit app that just calls sleep (on FreeBSD 12.1 amd64) then I see at the end of the map 22353 0xfbffe000 0xfffde000 ---00 0 0 - -- 22353 0xfffde000 0xe000 rw-33 1 0 ---D- df 22353 0xe000 0xf000 r-x11 94 0 - ph I think the last block is for signal handlers and the last but one block is the user stack. But what is between 0xfbffe000 and 0xfffde000? It's a bit less than 64Mbytes. This has no protection flags, no resident pages or references and no type. My guess is that this is some sort of guard page for the user stack. Can anyone confirm this? Also, does anyone know if this has been present in FreeBSD for a long time? My copy of “The Design and Implementation of FreeBSD" 2e doesn't show anything between stack and shared libraries. 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"
RO Elf program headers
Hi I’ve been working on getting Valgrind to work again on FreeBSD. Probably the biggest problem at the moment is that Valgrind doesn’t (yet) handle the read-only program headers. If I run “readelf -l libc++.so.1.0” on Linux I see two LOAD headers, the first one “R E” (read-execute) and the second one “RW” (read-write). If I do the same on FreeBSD then I see a third program header which is “R” (read-only), before the other two. My questions are - Does anyone know when this extra header was added? (I assume that it was added sometime in the past 5 years or so) - What is in these segments, and is it safe to assume that multiple shared libraries can map the same RO content to the same address? 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"
