When vgdb replies to qRcmd packet recieved from GDB, it
used to send the reply as simple string. This is wrong,
GDB expects to get a hex encoded string.
Paul Floyd [Sun, 26 Nov 2023 09:23:34 +0000 (10:23 +0100)]
FreeBSD regtest: make aio test more robust
Had to remove a few of the errors - seems to me that aio errors
are not handled well by the FreeBSD kernel. E.g., it looks
like the error state doesn't get cleared by aio_return.
Paul Floyd [Sat, 18 Nov 2023 12:02:30 +0000 (13:02 +0100)]
Bug 428364 - Signals inside io_uring_enter not handled
Patch provide by
Andrew Soutar kdebugtraq@andrewsoutar.com
Thanks!
I haven't added the reproducers as they require interrupting
the Valgrind process. Maybe the tests can be adapted to use
fork and have the parent kill the child running io_uring.
Paul Floyd [Sat, 18 Nov 2023 06:34:00 +0000 (07:34 +0100)]
Darwin: remove global variable used in aio_return
This was using a global variable to signify a read success
between pre- and post- aio_return. I don't think that this
was safe. There could be multiple calls to aio_return on
different threads. The global aiocpb_table is safe enough
as the pointers to control block are unique. However if two
threads manipulate was_a_successful_aio_read there's no way
of telling them apart. Rather than trying to make
was_a_successful_aio_read thread safe I did the same as on
FreeBSD and removed post- aio_return and now do everything
in pre- aio_return. No global variable, no thread hazard.
Adds syscall wrappers for aio_readv and aio_writev
Also rewrote the wrappers for aio_read, aio_write and aio_return
as they weren't correctly checking the async memory.
The code is similar th that of Darwin with one exception.
Darwin uses a global variable to communicate between the
pre- and post- aio_return wrappers. I don't think that is
safe when there are multiple aio reads in flight. Instead
I put everything in the pre- aio_return wrapper.
Paul Floyd [Sun, 5 Nov 2023 12:35:01 +0000 (13:35 +0100)]
Bug 476535 - Difference in allocation size for massif/tests/overloaded-new between clang++/libc++ and g++/libstdc++
In the end all I could do was filter the results.
libc++ and libstdc++ allocate different sizes of stuff for their own usr.
That means that when we get to allocating aligned blocks there is some
slop (up to the alignment size) that gets counted. And the amount of
that slop depends on the prior (internal) allocations.
Paul Floyd [Sun, 5 Nov 2023 09:59:43 +0000 (10:59 +0100)]
massif regtest: make verbose tests work on both 32bit and 64bit
Now alloc fns only have the appropriate new overloads which
means 32bit has unsigned size but 64bit has unsigned long.
Filter the unsigned long to unsigned.
Paul Floyd [Sun, 5 Nov 2023 09:06:56 +0000 (09:06 +0000)]
massif regtest: try adding a new expected for overloaded-new
Added a filter for "pool" that's used on Arch Linux
I'm not too confident that the new expected will work for
all architectures or even versions of libstdc++
Paul Floyd [Fri, 3 Nov 2023 20:46:13 +0000 (21:46 +0100)]
FreeBSD: remove some massif regtest expecteds
These were added mainly to have a cleanish slate with GCC on FreeBSD.
Unfortunately FreeBSD doesn't have dependent packages, so no debuginfo
for libstdc++ and the GCC port libstdc++ is stripped. That means that
the filters for internal GCC allocations don't work.
Since I hardly use GCC any more I'm getting rid of these expecteds.
Mark Wielaard [Thu, 2 Nov 2023 18:50:07 +0000 (19:50 +0100)]
Do not run memcheck/tests/x86-linux/scalar when root
The test expects some syscalls to fail, but when run as root
the user actually has permission to do silly things. So skip
the test if we notice we are root.
Mark Wielaard [Mon, 30 Oct 2023 22:30:06 +0000 (23:30 +0100)]
Disable memcpy overlap check and test on amd64 linux
Almost all newer distros have ifunc based memcpy/memmove glibc
implementation which cause false positives. Disable the overlap check
and test on these systems for now.
Andreas Arnez [Thu, 26 Oct 2023 12:00:52 +0000 (14:00 +0200)]
s390x regtest: Activate 128 bit SIMD tests for s390x in vbit-test
The vbit-test test case is currently configured to exclude s390x from the
platforms that execute the 128 bit SIMD irop tests. Since there's no
known issue with those, they can be activated on s390x as well.
Mark Wielaard [Thu, 26 Oct 2023 10:25:44 +0000 (12:25 +0200)]
vg_replace_malloc DELETE should not check size
The DELETE replacement functions check the size argument, but this
doesn't actually exist. Only the DELETE_SIZED replacement functions
get a size (and should check it).
On i386 (fedora gnu/linux) this causes the following failures:
Bug 432801 - Valgrind 3.16.1 reports a jump based on uninitialized
memory somehow related to clang and signals
Add support for precise computation of SIMD greater-than on
amd64 and x86.
This adds support for 64bit, 16bit, and 8bit to the existing 32bit
support.
The Iop_CmpGT64Ux2 is only supported on PPC32 and PPC64. The above
commit adds a more precise method, expensiveCmpGT, for setting the
vibits for the Iop_CmpGT64Ux2 Iop.
The expected results for the vbit test were not updated to the new more
precise results. This patch updates the expected results for the Iop.
Andreas Arnez [Thu, 19 Oct 2023 12:17:35 +0000 (14:17 +0200)]
s390x regtest: Fix memcheck tests for cu21 and cu42 with Clang
When compiled with Clang, the s390x memcheck tests for cu21 and cu42 yield
different line number information for the inline assemblies. Using gcc,
the inline assemblies do not receive updated line number information
because they are phrased as if they were data, not code. See also the
discussion in https://sourceware.org/bugzilla/show_bug.cgi?id=30206
Fix this by rephrasing the inline assemblies in cu21 and cu42 to normal
instructions, using the respective mnemonics. Since this affects the line
number information, adjust the expected test output files as well.
Andreas Arnez [Tue, 16 May 2023 18:29:33 +0000 (20:29 +0200)]
s390x: Fix memcheck false positives with certain comparisons
Consider this structure definition:
struct s {
unsigned b : 1;
unsigned c : 1;
} x;
Then certain compiler optimizations for a big-endian system may transform
the test
if (x.b || x.c)
...
into a comparison `> 0x3f' of the structure's first byte. Indeed, the
result of this comparison only depends on the two highest bits of the
byte. Thus, even if the lower bits are undefined, memcheck shouldn't
complain, but it does.
For certain cases this can be fixed. Do this by detecting comparisons
like this in the condition code helper for S390_CC_OP_UNSIGNED_COMPARE and
transforming them to a test for the selected bits instead. Add a small
test to verify the fix.
git://sourceware.org / valgrind.git / log