=== Valgrind: preparing for 15.0-RELEASE

Links: +
link:https://www.valgrind.org/[Valgrind Home Page] URL: link:https://www.valgrind.org/[] +
link:https://www.valgrind.org/docs/manual/dist.news.html[Valgrind News] URL: link:https://www.valgrind.org/docs/manual/dist.news.html[] +
link:https://github.com/paulfloyd/freebsdarm64_valgrind[arm64 port] URL: link:https://github.com/paulfloyd/freebsdarm64_valgrind[]

Contact: Paul Floyd <pjfloyd@wanadoo.fr>

I have not submitted any reports for over a year.
On the whole that is good news as it means that there have not been any major issues.
Back then I said that aarch64 support was about to land and indeed it did in mid April 2024.

I added a nice little script for use with Valgrind called `vgscript`.
This works in a similar manner to `pstack` (or `bstack` on FreeBSD) in that you give it a PID and it will generate a stack trace for that process.
If you use `bstack` with a Valgrind process you will see the Valgrind call stack which is probably of no use to you.
If you run `vgstack` with a Valgrind PID it will print the call stack of the test exe running under Valgrind.

If you use Valgrind regularly could you take a look and answer the survey that I posted on the forums (if you have not done so already).
Here is the link:https://forums.freebsd.org/threads/valgrind-feature-poll.98707/#post-716085[link].

Valgrind 3.26 is due out at the end of October 2025 and package:devel/valgrind[] will be updated shortly after that.

package:devel/valgrind-devel[] will get one (or maybe more) updates as I fix issues with FreeBSD 15.0.

The outstanding issues that I have on FreeBSD 15.0 are
* aarch64: there is a problem when using Valgrind with gdb/vgdb.
  Hitting ctrl-c to interrupt the process running under Valgrind does not work and Valgrind crashes with an assert.
* aarch64: a known old issue that was infrequent regarding initialisation of thread memory now seems to occur much more often.
* amd64: maybe similar to the first issue with gdb/vgdb and interrupting a process, but this time I am seeing `select` return an 'impossible' value.
* amd64: a test for `setcred` is getting an extra "Conditional jump" error message.

Most of the above are not too serious unless you are a heavy user of gdb/vgdb.

Here is a list of bugfixes since my last report, Q1 2024.

* Several suppressions added for libc, libc++ and libstdc++ functions
* Improvements to `setcontest` argument checking
* Some more `aio_*` fixes
* Syscall `_sysctlname` was checking the wrong length of the name argument
* New syscall wrappers for `kcmp`, `getrlimitusage`, `close_range`, `fchroot`, `setcred`, `exterrctl`, `inotify_add_watch_at`, `inotify_rm_watch`, `jail_attach_jd` and `jail_remove_jd`
* Started adding better `ioctl` argument checking
* Fixes to Valgrinds self-checking modes
* Support aarch64 auxv AT_HWCAP, AT_CHERI_STATS, AT_HWCAP3 and AT_HWCAP4
* Valgrind file descriptor checking has been significantly enhanced and this includes FreeBSD
* Some old code that I could never test for FreeBSD 10 has been removed
* Removed as much as possible FreeBSD version dependent code. This reduces everyday maintenance at the cost of making version-independent regression tests more difficult
* Turn off check for lock created during text handling that will deliberately leak
* Syscall `sigwait` was not correctly dealing with its atypical return value
* Improved checking of `utrace` syscall arguments
* amd64: syscall arguments 7 and 8 were swapped (it turns out that argument 8 is never needed and has been removed)
* amd64: added `sysarch` subcommands `AMD64_SET_TLSBASE` and `AMD_GET_TLSBASE`
* Reduced warnings that get printed in quiet (-q) mode
* Improved checking done by `sysctl` kern.proc.pathname
* Handle `mmap` MAP_STACK and MAP_GUARD
* Syscalls `open*` now produce an error if you try to open the guest exe for writing
* Syscalls `sigwait` and `sigwaitingfo` were too lax in accepting NULL arguments
* Many of the `*at` system calls (like `faccessat`) were not checking that the directory fd is not one of the file descriptors reserved for Valgrind's use
* Function `memalign` now accepts a size of zero