Carl Love [Fri, 3 Sep 2021 17:14:50 +0000 (17:14 +0000)]
Fix impossible constraint issue in P10 testcase.
This reworks the modulo operation as seen in
valgrind/none/tests/ppc64/test_isa_3_1_common.c:
initialize_source_registers().
Due to a GCC issue (PR101882), we will try to avoid a modulo operation with
both input and outputs set to a hard register. In this case, we can apply
the modulo operation to the args[] array value used to initialize the ra
value.
Andreas Arnez [Tue, 18 May 2021 17:59:32 +0000 (19:59 +0200)]
s390x: Wrap up misc-insn-3 and vec-enh-2 support
Wrap up support for the miscellaneous-instruction-extensions facility 3
and the vector-enhancements facility 2: Add 'case' statements for the
remaining unhandled arch13 instructions to 'guest_s390_toIR.c', document
the new support in 's390-opcodes.csv', adjust 's390-check-opcodes.pl', and
announce the new feature in 'NEWS'.
Andreas Arnez [Mon, 17 May 2021 13:34:15 +0000 (15:34 +0200)]
s390x: Vec-enh-2, test cases
Add test cases for verifying the new/enhanced instructions in the
vector-enhancements facility 2. For "vector string search" VSTRS add a
memcheck test case.
Andreas Arnez [Tue, 16 Feb 2021 16:52:09 +0000 (17:52 +0100)]
s390x: Mark arch13 features as supported
Make the STFLE instruction report the miscellaneous-instruction-extensions
facility 3 and the vector-enhancements facility 2 as supported. Indicate
support for the latter in the HWCAP vector as well.
Andreas Arnez [Wed, 10 Mar 2021 18:22:51 +0000 (19:22 +0100)]
s390x: Vec-enh-2, VSTRS
Support the new "vector string search" instruction VSTRS. The
implementation is a full emulation and follows a similar approach as for
the other vector string instructions.
Andreas Arnez [Tue, 16 Feb 2021 15:19:31 +0000 (16:19 +0100)]
s390x: Vec-enh-2, VLBR and friends
Add support for the new byte- and element-swapping vector load/store
instructions VLEBRH, VLEBRG, VLEBRF, VLLEBRZ, VLBRREP, VLBR, VLER,
VSTEBRH, VSTEBRG, VSTEBRF, VSTBR, and VSTER.
Andreas Arnez [Thu, 11 Feb 2021 19:02:03 +0000 (20:02 +0100)]
s390x: Vec-enh-2, extend VCDG, VCDLG, VCGD, and VCLGD
The vector-enhancements facility 2 extends the vector floating-point
conversion instructions VCDG, VCDLG, VCGD, and VCLGD. In addition to
64-bit elements, they now also handle 32-bit elements. Add support for
these new forms.
Andreas Arnez [Wed, 7 Apr 2021 10:29:32 +0000 (12:29 +0200)]
s390x: Vec-enh-2, extend VSL, VSRA, and VSRL
The vector-enhancements facility 2 extends the existing bitwise vector
shift instructions VSL, VSRA, and VSRL. Now they allow the shift
vector (the third operand) to contain different shift amounts for each
byte. Add support for these new forms.
Add support for the instructions NCRK, NCGRK, NNRK, NNGRK, NORK, NOGRK,
NXRK, NXGRK, OCRK, and OCGRK. Introduce a common helper and use it for
the existing instructions NRK, NGRK, XRK, XGRK, ORK, and OGRK as well.
Mark Wielaard [Fri, 6 Aug 2021 17:08:17 +0000 (19:08 +0200)]
unhandled ppc64le-linux syscall: 252 (statfs64) and 253 (fstatfs64)
glibc 2.34 consolidated all statfs implementations. All other arches
that have statfs64/fstat64 (including ppc32) already had that syscall
hooked up, it was just ppc64 that was missing it.
Mark Wielaard [Wed, 21 Jul 2021 17:53:13 +0000 (19:53 +0200)]
Generate a ENOSYS (sys_ni_syscall) for clone3 on all linux arches
glibc 2.34 will try to use clone3 first before falling back to
the clone syscall. So implement clone3 as sys_ni_syscall which
simply return ENOSYS without producing a warning.
Mark Wielaard [Fri, 16 Jul 2021 19:47:08 +0000 (15:47 -0400)]
Update helgrind and drd suppression libc and libpthread paths in glibc 2.34
glibc 2.34 moved all pthread functions into the main libc library.
And it changed the (in memory) path of the main libc library to
libc.so.6 (before it was libc-2.xx.so).
This breaks various standard suppressions for helgrind and drd.
Fix this by doing a configure check for whether we are using glibc
2.34 by checking whether pthread_create is in libc instead of in
libpthread. If we are using glibc then define GLIBC_LIBC_PATH and
GLIBC_LIBPTHREAD_PATH variables that point to the (regexp) path
of the library that contains all libc functions and pthread functions
(which will be the same path for glibc 2.34+).
Rename glibc-2.34567-NPTL-helgrind.supp to glibc-2.X-helgrind.supp.in
and glibc-2.X-drd.supp to glibc-2.X-drd.supp.in and replace the
GLIBC_LIBC_PATH and GLIBC_LIBPTHREAD_PATH at configure time.
The same could be done for the glibc-2.X.supp.in file, but hasn't
yet because it looks like most suppressions in that file are obsolete.
Mark Wielaard [Fri, 16 Jul 2021 19:37:21 +0000 (21:37 +0200)]
gdbserver_tests: update filters for newer glibc/gdb
With newer glibc/gdb we might see a __select call without anything
following on the line. Also when gdb cannot find a file it might
now print "Inappropriate ioctl for device" instead of the message
"No such file or directory"
amd64 front end: Make uses of 8- and 16-bit GPRs GET the entire containing register.
Until now, a read of a 32-bit GPR (eg, %ecx) in the amd64 front end actually
involved GETting the containing 64-bit reg (%rcx) and dropping off its top
32-bits, in the IR translation. This makes IR optimisation work well for code
that mixes 32 and 64 bit integer operations, which is very commont. In
particular it helps guarantee that PUT-to-GET and redundant-GET optimisations
work, hence that constant propagation/folding across such boundaries works,
and indirectly helps to avoid generating code in the back end that suffers
from store-forwarding or partial-register-read stalls.
This commit partially extends those advantages to 8- and 16-bit GPR reads. In
particular, all 16-bit GPR fetches are now a GET of the whole 64-bit register
followed by an Iop_64to16 cast. The same scheme is used for 8-bit register
fetches, except for the "anomalous four" (%ah, %bh, %ch, %dh), whose handling
is left unchanged.
With this in place, now, a wider write followed by a smaller read, will play
nice with constant folding, propagation, for example (somewhat artificially):
movl $17, %ecx // 32-bit write of %rcx
shrl %cl, %r15 // 8-bit read of %rcx
The 17 will be propagated, in IR, up to the shift.
The commit also adds a couple more rewrite rules in ir_opt.c to remove some of
the resulting pointless conversion pairings.
Consistently set CC_NDEP when setting the flags thunk.
For most settings of the flags thunk (guest_CC_{OP,DEP1,DEP2,NDEP}), the value
of the NDEP field is irrelevant, because of the setting of the OP field, and
so it is usually not set in such cases, which are the vast majority. This
saves a store (a PUT) in the final generated code. But it has the bad effect
that the IR optimiser cannot know that preceding PUTs to the field are
possibly dead and can be removed. Most of the time that is not important, but
just occasionally it can cause a lot of pointless extra computation (calling
of amd64g_calculate_rflags_all) to happen. This was observed in a long basic
block involved in a hash calculation, like this:
rolq .. // sets CC_NDEP to the previous value of the flags,
// as calculated by amd64g_calculate_rflags_all
mulq ..
(rolq/mulq repeated several times)
addq .. // effect is, all of the flag computation done for the rol/mul
// sequence is irrelevant, but iropt can't see that
Setting CC_NDEP consistently to zero, even if it isn't needed, avoids the
problem.
amd64 front end: more spec rules: S/NS after LOGICW, S after SHRL, Z after SHRW, C after SUBW.
This adds a few more spec rules that seem useful for running Firefox built
with gcc-O3 and clang-O3. At least one of them removes a false Memcheck
error.
There is also some improved debug printing, currently #if 0'd.
Remove redundant assertions and conditionals in move_CEnt_to_top.
move_CEnt_to_top is on the hot path when reading large amounts of debug info,
especially Dwarf inlined-function info. It shows up in 'perf' profiles. This
commit removes assertions which are asserted elsewhere, and tries to avoid a
couple of conditional branches.
Reimplement h_generic_calc_GetMSBs8x16 to be more efficient.
h_generic_calc_GetMSBs8x16 concatenates the top bit of each 8-bit lane in a
128-bit value, producing a 16-bit scalar value. (It is PMOVMSKB, really).
The existing implementation is excessively inefficient and shows up sometimes
in 'perf' profiles of V. This commit replaces it with a logarithmic (4-stage)
algorithm which is hopefully much faster.
Carl Love [Fri, 11 Jun 2021 15:59:53 +0000 (10:59 -0500)]
PPC64 Enable the MMA bit in the HWCAP.
The MMA bit should have been enabled when the last of the MMA instructions
were committed. Also, the header comments about filtering out the DARN
and SCV support should have been updated when DARN and SCV support was added.
Andreas Arnez [Mon, 7 Jun 2021 12:01:53 +0000 (14:01 +0200)]
s390x: Don't emit "vector or with complement" on z13
The z/Architecture instruction "vector or with complement" (VOC) can be
used as an optimization to combine "vector or" with "vector nor". This is
exploited in Valgrind since commit 6c1cb1a0128b00858b973e. However, VOC
requires the vector-enhancements facility 1, which is not installed on a
z13 CPU. Thus Valgrind can now run into SIGILL on z13 when trying to
execute vector string instructions.
Fix this by suppressing the VOC optimization unless the
vector-enhancements facility 1 is recognized on the host.
Andreas Arnez [Tue, 30 Mar 2021 15:45:20 +0000 (17:45 +0200)]
s390x: Fix/optimize Iop_64HLtoV128
In s390_vr_fill() in guest_s390_toIR.c, filling a vector with two copies
of a 64-bit value is realized with Iop_64HLtoV128, since there is no such
operator as Iop_Dup64x2. But the two args to Iop_64HLtoV128 use the same
expression, referenced twice. Although this hasn't been seen to cause
real trouble yet, it's problematic and potentially inefficient, so change
it: Assign to a temp and pass that twice instead.
In the instruction selector, if Iop_64HLtoV128 is found to be used for a
duplication as above, select "v-vdup" instead of "v-vinitfromgprs". This
mimicks the behavior we'd get if there actually was an operator
Iop_Dup64x2.
Andreas Arnez [Fri, 26 Mar 2021 18:27:47 +0000 (19:27 +0100)]
s390x: Rework insn "v-vdup" and add "v-vrep"
So far the only s390x insn for filling a vector with copies of the same
element is "v-vdup" (S390_VEC_DUPLICATE), which replicates the first
element of its vector argument. This is fairly restrictive and can lead
to unnecessarily long code sequences.
Redefine "v-vdup" to replicate any scalar value instead. And add
"v-vrep" (S390_INSN_VEC_REPLICATE) for replicating any given element of a
vector. Select the latter for suitable expressions like
Iop_Dup8x16(Iop_GetElem8x16(vector_expr, i))
This improves the generated code for some vector string instructions,
where a lot of element replications are performed.
Andreas Arnez [Tue, 23 Mar 2021 13:55:09 +0000 (14:55 +0100)]
s390x: Improve handling of amodes without base register
Addressing modes without a base or index register represent constants.
They can occur in some special cases such as shift operations and when
accessing individual vector elements. Perform some minor improvements to
the handling of such amodes.
Andreas Arnez [Fri, 16 Apr 2021 10:44:44 +0000 (12:44 +0200)]
Bug 434296 - s390x: Add memcheck test cases for vector string insns
Bug 434296 addresses memcheck false positives with the vector string
instructions VISTR, VSTRC, VFAE, VFEE, and VFENE. Add test cases that
verify the fix for that bug. Without the fix, memcheck yields many
complains with these tests, most of which are false positives.
Andreas Arnez [Tue, 27 Apr 2021 18:13:26 +0000 (20:13 +0200)]
Bug 434296 - s390x: Rework IR conversion of VISTR
The z/Architecture instruction VISTR is currently transformed to a dirty
helper that executes the instruction. This can cause false positives with
memcheck if the input string contains undefined characters after the
string terminator. Implement without a dirty helper and emulate the
instruction instead.
Andreas Arnez [Tue, 2 Mar 2021 13:12:29 +0000 (14:12 +0100)]
Bug 434296 - s390x: Rework IR conversion of VFENE
So far the z/Architecture instruction "vector find element not
equal" (VFENE) is transformed to a loop. This can cause spurious
"conditional jump or move depends on uninitialised value(s)" messages by
memcheck. Re-implement without a loop.
Andreas Arnez [Thu, 18 Mar 2021 17:01:10 +0000 (18:01 +0100)]
Bug 434296 - s390x: Rework IR conversion of VSTRC, VFAE, and VFEE
The z/Architecture instructions "vector string range compare" (VSTRC),
"vector find any element equal" (VFAE), and "vector find element
equal" (VFEE) are each implemented with a dirty helper that executes the
instruction. Unfortunately this approach leads to memcheck false
positives, because these instructions may yield a defined result even if
parts of the input vectors are undefined. There are multiple ways this
can happen: Wherever the flags in the fourth operand to VSTRC indicate
"match always" or "match never", the corresponding elements in the third
operand don't affect the result. The same is true for the elements
following the first zero-element in the second operand if the ZS flag is
set, or for the elements following the first matching element, if any.
Re-implement the instructions without dirty helpers and transform into
lengthy IR instead.
Andreas Arnez [Wed, 7 Apr 2021 14:48:29 +0000 (16:48 +0200)]
s390x: Support "expensive" comparisons Iop_ExpCmpNE32/64
Add support for Iop_ExpCmpNE32 and Iop_ExpCmpNE64 in the s390x instruction
selector. Handle them exactly like the "inexpensive" variants Iop_CmpNE32
and Iop_CmpNE64.
Andreas Arnez [Wed, 28 Apr 2021 16:52:30 +0000 (18:52 +0200)]
Bug 433863 - s390x: Remove memcheck test cases for cs, cds, and csg
The fix for bug 429864 - "s390x: C++ atomic test_and_set yields
false-positive memcheck diagnostics" changes the memcheck behavior at
various compare-and-swap instructions. The comparison between the old and
expected value now always yields a defined result, even if the input
values are (partially) undefined. However, some existing test cases
explicitly verify that memcheck complains about the use of uninitialised
values here. These test cases are no longer valid. Remove them.
Andreas Arnez [Tue, 30 Mar 2021 16:10:43 +0000 (18:10 +0200)]
s390x: Add missing UNOP insns to s390_insn_as_string
Some unary operator insns are not handled by s390_insn_as_string(). If
they are encountered while the appropriate trace flag is set, a vpanic
occurs. Fix this: add handling for the missing insns.
Yi Fan Yu [Thu, 1 Apr 2021 19:31:47 +0000 (15:31 -0400)]
drd/tests/swapcontext: Add SIGALRM handler to avoid stacktrace
During testing for oe-core build on QEMU,
SIGALRM can trigger during nanosleep.
This results a different stderr output than expected.
```
==277== Process terminating with default action of signal 14 (SIGALRM)
==277== at 0x36C74C3943: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:43)
==277== by 0x36C74C8726: nanosleep (nanosleep.c:25)
```
This stacktrace printing will not occur
if we add a handler that simply exits.
To improve its results, Callgrind does special handling for
the runtime linker entry point to resolve symbols. However,
it only used the exact symbol name "_dl_runtime_resolve",
as well as specific machine code templates (when the runtime
linker was stripped from symbol names) as basis.
Recent glibc added multiple similar symbol names as variants,
such as _dl_runtime_resolve_xsave.
The above-mentioned commit 86277041 solves this by extending
the check for machine code templates for specific Linux
distributions.
This patch extends this for more architectures and variants
by checking if a function starts with "_dl_runtime_resolve".
Furthermore, the original function names of the variants
still are visible in the output (and not forced to the prefix).
While the heuristic that every function symbol starting
with the prefix "_dl_runtime_resolve" as being an entry point
into the runtime linker for resolving a function address may
be a bit rough, this prefix is not expected to be used often in
other source code for anything else.
The worst case is a slightly misleading call graph only
visible in a very specific situation: if the wrongly-detected
function does a tail call (ie instead of returning, jumping
to another function), it will be shown as 2 calls in a row
from the original caller.
Bart Van Assche [Tue, 23 Mar 2021 02:12:20 +0000 (19:12 -0700)]
configure, drd: Only build the swapcontext test if swapcontext() is available
Add a configure test for swapcontext() since MUSL does not provide a
swapcontext() implementation. See also
https://bugs.kde.org/show_bug.cgi?id=434775 .
Julian Seward [Wed, 17 Mar 2021 07:10:49 +0000 (08:10 +0100)]
Bug 401416 - Compile failure with openmpi 4.0.
In short, use the missing symbol names only when compiling against OpenMPI
version 3 or below, or when compiling against a non-OpenMPI implementation.
Modified version of a patch originally from Mark Wielaard.
Julian Seward [Sat, 13 Mar 2021 18:20:50 +0000 (19:20 +0100)]
amd64 front end: try to avoid a Memcheck false positive related to CPUID. n-i-bz.
In the amd64 front end, CPUID is implemented by calling dirty helper. The way
the side-effects for this call are declared can lead to false positives from
Memcheck. This is a somewhat inelegant "fix", but it's the least-worst that
can be done without changing parameter-passing for the helper functions
involved. A big in-line comment explains the problem and fix.
Andreas Arnez [Fri, 5 Mar 2021 19:16:46 +0000 (20:16 +0100)]
s390x: Improve isel for Iop_V128to64 and friends
The existing instruction selector for Iop_V128to64, Iop_V128HIto64, and
Iop_V128to32 stores the vector register on the stack and then reads the
requested integer value back from the stack into the target GPR. This is
fairly inefficient.
Load the requested value directly from the vector register into the target
GPR instead, using S390_VEC_GET_ELEM.
Mark Wielaard [Tue, 9 Mar 2021 17:51:57 +0000 (18:51 +0100)]
vgdb might crash if valgrind is killed
This is an odd corner case, but happens specifically with the gdb
testcase make check TESTS=gdb.base/valgrind-infcall-2.exp. At the
end valgrind gets killed with SIGKILL (-9) which cannot be blocked.
But vgdb at the time is inside waitstopped. It sees the process wasn't
exited (WIFEXITED(status) is false) and so assumes the process was
stopped by a signal. Which it asserts:
assert (WIFSTOPPED(status));
signal_received = WSTOPSIG(status);
if (signal_received == signal_expected)
break;
But the assert fails and vgdb dumps core. The gdb testcase doesn't care,
because it already finished its test and just makes sure all processes
are gone. But it slowly fills your disk with core files (if you have
enabled them) when running the testsuite.
The fix is to simply check first whether the program has termined
normally or by getting a fatal signal.
Fix nlcontrolc.vgtest hanging on newer glibc and/or arm64
This test verifies that GDB can interrupt a process with all threads
blocked in a long select syscall.
The test used to terminate by having GDB modifying the select argument.
However, modifying the select argument works only for specific arch
and/or specific versions of glibc.
The test then blocks on other architectures/glibc versions.
The previous version of the test was:
* first launching sleepers so as to have all threads blocked in long select
* interrupting these threads
* changing the select time arg so that the threads burn cpu
* and then change variables to have the program exit.
The new version does:
* first launches sleepers so that all threads are burning cpu.
* interrupting these threads
* change the local variables of sleepers so that the threads will
block in a long select syscall
* interrupt these threads
* kill the program.
With this new version, we still check the behaviour of gdb+vgdbserver
for both burning and sleep threads, but without having the termination
depending on modifying select syscall argument.
Tested on debian amd64 and on ubuntu arm64 (to check the test does not hang
on an arm64 platform).
Carl Love [Sat, 2 May 2020 04:49:33 +0000 (23:49 -0500)]
ISA 3.1 VSX Mask Manipulation Operations
Add support for:
mtvsrbmMove to VSR Byte Mask
mtvsrbmiMove To VSR Byte Mask Immediate
mtvsrdmMove to VSR Doubleword Mask
mtvsrhmMove to VSR Halfword Mask
mtvsrqmMove to VSR Quadword Mask
mtvsrwmMove to VSR Word Mask
vcntmbbVector Count Mask Bits Byte
vcntmbdVector Count Mask Bits Doubleword
vcntmbhVector Count Mask Bits Halfword
vcntmbwVector Count Mask Bits Word
vexpandbmVector Expand Byte Mask
vexpanddmVector Expand Doubleword Mask
vexpandhmVector Expand Halfword Mask
vexpandqmVector Expand Quadword Mask
vexpandwmVector Expand Word Mask
vextractbmVector Extract Byte Mask
vextractdmVector Extract Doubleword Mask
vextracthmVector Extract Halfword Mask
vextractqmVector Extract Quadword Mask
vextractwmVector Extract Word Mask
Re-implemented the copy_MSB_bit_fields() function. It can be done similarly to
the implementation of the vgnb instruction leveraging the clean helpers
used for the vgnb instruction.
Reimplemented the vexpandXm instructions eliminating
the call to copy_MSB_bit_fileds() and the need for the
for(i = 0; i< max; i++) loop.
Reimplemented the mtvsrXm instructions to remove the
need for the for(i = 0; i< max; i++) loop.
The computations for vexpandXm and mtvsrXm instructions
can be done much more efficiently.
Mark Wielaard [Thu, 4 Mar 2021 18:24:06 +0000 (19:24 +0100)]
arm64: Handle sp, lr, fp as DwReg in CfiExpr
When copy_convert_CfiExpr_tree sees a DwReg on arm64 we simply call
I_die_here; This causes an issue in the case we really do have to handle
that case (see https://bugzilla.redhat.com/show_bug.cgi?id=1923493).
Handle the stack pointer (sp), link register (x30) and frame pointer (x29),
which we already keep in D3UnwindRegs, like we do for other architectures
in evalCfiExpr and copy_convert_CfiExpr_tree.
Paul Floyd [Wed, 3 Mar 2021 07:53:51 +0000 (08:53 +0100)]
Keep on churning.
Without #define _XOPEN_SOURCE macports clang 9.0.1 on OSX 10.7.5 was
giving me
In file included from swapcontext.c:12:
/usr/include/ucontext.h:43:2: error: The deprecated ucontext routines require
_XOPEN_SOURCE to be defined
^
swapcontext.
So I added #define _XOPEN_SOURCE
But that gives, on Solaris 11.3
In file included from /usr/include/limits.h:12:0,
from /usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/include-fixed/limits.h:168,
from /usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/include-fixed/syslimits.h:7,
from /usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/include-fixed/limits.h:34,
from swapcontext.c:7:
/usr/include/sys/feature_tests.h:354:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"
#error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
^
So make the #define _XOPEN_SOURCE conditional on darwin.
Paul Floyd [Tue, 2 Mar 2021 16:48:14 +0000 (17:48 +0100)]
Modify cxx17_aligned_new testcase to accommdate clang.
Explicitly use ordinary scalar delete and update the expecteds.
Otherwise g++ uses sized scalar delete whilse clang uses
ordinary scalar delete which causes a diff.
Mark Wielaard [Sun, 28 Feb 2021 23:39:31 +0000 (00:39 +0100)]
Remove deep-D.post.exp-ppc64 from EXTRA_DIST.
massif/tests/deep-D.post.exp-ppc64 was remove in commit 24a94df73
"VG_(get_fnname_kind): Recognize gcc "optimized" below main functions."
but was still listed in massif/tests/Makefile.am (EXTRA_DIST). Causing
make dist to fail.
Mark Wielaard [Sun, 28 Feb 2021 23:26:00 +0000 (00:26 +0100)]
VG_(get_fnname_kind): Recognize gcc "optimized" below main functions.
The VG_(get_fnname_kind) function detects some special "below main"
function names. Specifically __libc_start_main and generic_start_main
both of which are used to call the actual main () function from the
application. We already recognized one variant, generic_start_main.isra.0,
but only for powerpc. Recognize all possibly specialed optimized variants
gcc can produce by simply checking for the function name with dot as
prefix. This fixes the memcheck/tests/supp_unknown.vgtest and
massif/tests/deep-D.vgtest with gcc 11.
We can now also get rid of the special cases in
massif/tests/deep-D.post.exp-ppc64 and memcheck/tests/supp_unknown.supp.
Mike Hommey [Fri, 26 Feb 2021 08:09:52 +0000 (17:09 +0900)]
sys_newfstatat: don't complain if |file_name| is NULL.
This is a followup to 2a7d3ae76, in the case rust code runs against a
glibc that supports statx but a kernel that doesn't, in which case glibc
falls back to fstatat.
git://sourceware.org / valgrind.git / log