C++ Valgrind on arm64

Paul Floyd · Mar 8, 2024

I'm close to being ready with a port of Valgrind on arm64 (currently only i386 and amd64 are officially supported).

I'd appreciate it if anyone could build and test it.

The git repo is here

GitHub - paulfloyd/freebsdarm64_valgrind

Contribute to paulfloyd/freebsdarm64_valgrind development by creating an account on GitHub.

github.com

To build, run the following
autogen.sh
configure --prefix=where_you_want_to_install
gmake
gmake install

Iif you have GCC installed run configure with "CC=clang CXX=clang++".
If you prefer not to install it, you can run it from the build directory with the script "vg-in-place".

There's one more issue that I'd like to iron out - DRD isn't detecting pthread_barrier issues. After that I'll push the code upstream and update the devel/valgrind-devel port.

I expect Valgrind 3.23 will be out by the end of April and I'll update devel/valgrind at that time.

zirias@ · Mar 13, 2024

Paul Floyd said:
I expect Valgrind 3.23 will be out by the end of April and I'll update devel/valgrind at that time.

As 13.3 is released now, how about a port revision pulling in https://sourceware.org/git/?p=valgrind.git;a=patch;h=32ca31e98245df31b311654d0ba5de232fe50265 ? Unfortunately it fails to build without that...

Paul Floyd · Mar 14, 2024

Please use devel/valgrind-devel

It's based on the sourceware code including the fix you mentioned.

I'll patch devel/valgrind if I start getting port build fallout, otherwise I'd rather concentrate on arm64 and other development.

Paul Floyd · Mar 14, 2024

And the arm64 port is now ready. I'll start the process of pushing it upstream(or if noone has time to review it, simply push it upstream).

zirias@ · Mar 14, 2024

Hi Paul Floyd -- the "issue" is you won't get any fallout until EOL of 13.2 because the builders won't be upgraded earlier, still 13.3 is a supported release now.

Your commit was easy enough to integrate: https://github.com/Zirias/zfbsd-ports/commit/3e90bf7293f3dc109b0d9f9e17b8189445ca9b9d

If you'd be fine with that, I'd happily push it (of course after some build testing and getting your approval).

Paul Floyd · Mar 14, 2024

If you are really seriously using Valgrind on FreeBSD then you should be building it from sourceware.

zirias@ · Mar 14, 2024

Uhm ... it's occassionally a very helpful tool for me when developing userspace apps, and I've been using the port so far without issues (so, thanks a lot for your work on it!). So are you telling me the port has (or is likely to have) some defects?

Paul Floyd · Mar 14, 2024

There are always many defects. Stuff that's changed since 3.22:

improvements to Massif handling of C++ new overloads
added a redir for reallocarray
a fix for strncat where the destination is the nul terminator of the source
aarch64 dotprod instructions
several fixes for aio* functions
elf loader fixes for binaries produced by mold
add a redir for memccpy
added a few default suppressions
more elf loader fixes for binaries without RW load sections
fixes for FreeBSD 15, in particular handling the new libsys
small ioctl improvements
support for FreeBSD 13.3
fix handling of mmap with O_DIRECT
fix for _umtx_op OP_ROBUST_LISTS
updates to man page
fix for amd64 rorx imm8
added redirs for C23 free_sized and free_aligned_sized
correctly propagate the ELF stack protection flags to the guest stack that Valgrind synthesizes
fixes for --sanity-level-3 and above
several fixes to checking done for semctl
fixed argument checking for utrace
added checking for duplicate file close when --track-fds=yes is specified
improved handling of closefrom

(I'm not counting stuff that's specific to Linux/Darwin/Solaris)

That's quite a lot, though not much has a major impact (unless you are using FreeBSD 15 or 13.3).

zirias@ · Mar 14, 2024

Paul Floyd I'll write you a quick PM because this thread is about aarch64 and I didn't expect my quick hint to spawn an unrelated discussion, sorry for derailing here!