Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create valgrind.adoc #120

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions website/content/en/status/report-2023-01-2023-03/valgrind.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
Valgrind - preparing for Valgrind 3.21

Links
Valgrind Home Page URL: https://www.valgrind.org/
Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html

Contact: Paul Floyd <pjfloyd@wanadoo.fr>

The devel/valgrind-devel port had an intermediate update which was submitted
on 2023-02-20. This contains most of what will be in the official release of
Valgrind 3.21 which is due out shortly after this status report.

There is a nice improvement to the vgdb interface. It's now much easier to
see which bits of memory are initialized or not. There are a couple of
fixes to the thread checks done by Helgrind.

FreeBSD specific, the address space limit has been raised to be the same as
Linux and Solaris on amd64. It was 32Gbytes and now it is 128Gbytes. The
kern.proc.pathname.PID has been fixed so that it returns the path of
the guest exe and not that the Valgrind host. At the same time I fixed
some _umtx_op false positives and corrected auxv AT_EXECPATH in a similar way
to kern.proc.pathname.PID. Syscall wrappers have been added for
sctp_generic_sendmsg and sctp_generic_recvgmsg.

Not yet available in the ports versions of Valgrind, there is a workaround
for the use of 'rfork'. Previously, since it is not supported, it would
cause Valgrind to abort. Now it fails gracefully setting either
EINVAL or ENOSYS. The main use of this syscall is in 'posix_spawn',
which will fallback to using 'vfork'. The 'mknodat' syscall wrapper was
incorrectly implemented on i386 and has now been fixed. There is a reworking
of all of the aligned allocation functions so that they behave less like
Linux glibc and more like the Valgrind build platform.