Running on a kernel that supports the SCV instruction (sets
PPC_FEATURE2_SCV in auxv AT_HWCAPS2) valgrind will assert: valgrind:
m_syswrap/syswrap-main.c:549 (getSyscallArgsFromGuestState): Assertion
'gst->guest_syscall_flag == SC_FLAG' failed.
Removing that assert makes most things work. But also filter out
PPC_FEATURE2_SCV from AT_HWCAPS2 for the client, so it shouldn't try
using the SCV instruction.
https://bugs.kde.org/show_bug.cgi?id=469097
commit 56ccb1e36c4722b56e3e602b986bc45025cb685d missed a few small
fixlets:
- one more comment at the top describing the three usages of vgdb.
- fixed up a few places where tabs were used for indentation (we are
not very consistent in that either, after the release we'll look
into adopting something like clang-format so you don't have to do
all this by hand).
- Add a missing newline in coregrind/m_main.c to make
none/tests/cmdline2 pass.
Remove --launched-with-multi from --help-debug output since it is not
a real user option. Do add a comment in m_main.c explaining the
internal usage.
Add a top-level comment describing the three usages of vgdb.
Fix comment description of decode_hexstring, create_packet,
split_hexdecode.
Consistently use 3 space indention in send_packet and receive_packet
and next_delim_string and split_hexdecode, count_delims,
do_multi_mode.
Fix return type of count_delims to size_t.
Add a note in coregrind/m_gdbserver/server.c to sync qSupported
replies with coregrind/vgdb.c.
Use vgdb (all lowercase) and GDB (all caps) consistently in the
manual.
The file descriptor is on non-blocking mode and read_buf should only
be called when poll gave us an POLLIN event signaling the file
descriptor is ready for reading from. Still sometimes we do get an
occasional EAGAIN. Just do as told in that case and try to read again.
Also fix an ERROR errno in getpkt. This has never been observed, but
not getting the actual errno if the write fails in that case would be
really confusing.
Executing vgdb --multi makes vgdb talk the gdb extended-remote
protocol. This means that the gdb run command is supported and
vgdb will start up the program under valgrind. Which means you
don't need to run gdb and valgrind from different terminals.
Also vgdb keeps being connected to gdb after valgrind exits. So
you can easily rerun the program with the same breakpoints in
place.
vgdb now implements a minimal gdbserver that just recognizes
a few extended-remote protocol packets. Once it starts up valgrind
it sets up noack and qsupported then it will forward packets
between gdb and valgrind gdbserver. After valgrind shutsdown it
resumes handling gdb packets itself.
https://bugs.kde.org/show_bug.cgi?id=434057
Co-authored-by: Mark Wielaard <mark@klomp.org>
Provide the user with a hint of what caused an out of memory error.
And explain that some memory policies, like selinux deny_execmem
might cause Permission denied errors.
Add an err argument to out_of_memory_NORETURN. And change
am_shadow_alloc to return a SysRes (all three callers were already
checking for errors and calling out_of_memory_NORETURN).
Adds a new warning to memcheck when realloc is used with a size of 0.
For a long time this has been "implementation defined" and so
non-portable. With C23 it will become UB.
Also adds a switch to turn off the error generation and a
second switch to select between the most common
"implementation" behaviours. The defaults for this second
switch are baked in at build time.
I think that these are all now done.
This commit refactors memalign and updates manual-core.xml
to say some behaviour of Valgrind depends on the build time
OS and libraries.
