[Valgrind-users] Anticipating valgrind 3.27.0

[Mark W. <ma...@kl...>]

We'll release Valgrind 3.27.0 later today. While making sure the NEWS
file was up to date I wrote about all the contributions made this
release. https://mastodon.nl/@mjw/tagged/valgrind

https://gnu.wildebeest.org/blog/mjw/2026/04/20/anticipating-valgrind-3-27-0/

Thanks all, and apologies if I missed something or someone.

Aaron Merey added two new options to helgrind.

To control helgrind tracing of internal synchronization, threading and
memory events use --show-events=1|2|3.

Use --track-destroy=no|yes|all to checks for missing
pthread_mutex_destroy and pthread_rwlock_destroy calls. With yes,
helgrind warns when pthread_mutex_init or pthread_rwlock_init is called
on the address of a live (undestroyed) lock. With all, Helgrind also
reports undestroyed locks at process exit.

Valgrind has separate VEX IR translators for AMD64 and x86 (32 bit)
code. While the AMD64 translator has seen support for new encodings and
instruction sets, the x86 translator has not.

Alexandra Hájková decided to port the SSE4.1 instruction set from the
AMD64 translator to the x86 translator and add backend support. This is
ongoing work, see the bug dependency tree
https://bugs.kde.org/showdependencytree.cgi?id=518222

But many more 32bit programs using SSE4.1 should now run under
Valgrind.

Andreas Arnez and Florian Krohm did a lot of work on the s390x support.

Andreas added support for new s390x z/Architecture features from the
15th edition. This enables running binaries compiled with -march=arch15
or -march=z17 and exploiting the new MSA extensions 10-13.

Florian	Krohm integrated binutils objdump for s390x disassembly in
VEX. And did a lot of s390x code and facilities cleanups.

s390x machine models older than z196 are no longer supported.

Andreas also showed there are still meaningful optimizations to be made
on how memcheck tracks undefinedness bits as outlined in the original
"Using Valgrind to detect undefined value errors with bit-precision"
https://valgrind.org/docs/memcheck2005.pdf paper.

His optimization of memcheck instrumenting a bitwise AND/OR with a
constant is clever and simplifies the generated code:
https://sourceware.org/cgit/valgrind/commit/?id=8514763a215f863bc52400991eba332df115eaea

Martin Cermak maintains the Linux Test Program (LTP) valgrind
integration, which checks our syscall wrappers work correctly. And he
makes sure newer linux syscalls are wrapped. Valgrind 3.27.0 adds
support for file_getattr, file_setattr, lsm_get_self_attr,
lsm_set_self_attr, lsm_list_modules. And corrects various syscall and
ioctl corner cases.

Martin also added Valgrind address space manager support for tracking
linux kernel lightweight guard pages, created through madvise
(MADV_GUARD_INSTALL).

These guard pages are very low overhead for the kernel because they
aren't tracked as separate VMAs and don't show up in the process proc
maps. But Valgrind does still need to know whether the addresses are
accessible. A new --max-guard-pages option controls the memory Valgrind
reserves for tracking these pages.

Paul Floyd had more commits than all others combined for this release.
Paul takes care of the alternative toolchains, Solaris/illumos, FreeBSD
and Darwin/MacOS ports.

Tested Oracle Solaris 11.4, OpenIndiana Hipster and OmniOS.

FreeBSD works on both amd64 and arm64, support for 16.0-CURRENT has
been added.

Supported MacOS versions, 10.13 (bug fixes), 10.14, 10.15, 11.0 (Intel
only), 12.0 (Intel only), 13.0 (Intel only, preliminary). No arm64
support yet.

A lot of code in valgrind 3.27.0 to support MacOS was previously
maintained by Louis Brunner out of tree
https://github.com/LouisBrunner/valgrind-macos

There are two new client requests (macros defined in valgrind.h)
https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-
adv.clientreq

- VALGRIND_REPLACES_MALLOC Returns 1 if the tool replaces malloc (e.g.,
memcheck). Returns 0 if the tool does not replace malloc (e.g.,
cachegrind and callgrind) or if the executable is not running under
Valgrind.

- VALGRIND_GET_TOOLNAME Get the running tool name as a string. Takes
two arguments, an input buffer pointer and the length of that buffer.