This is a supplement to commit 86277041
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.
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.
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.
mc_translate.c: enable further cases where scalar integer EQ/NE comparisons
use expensive instrumentation by default:
x86, amd64 for 16-bit comparisons
arm, arm64 for 32-bit comparisons
This fixes 'Bug 434193 - GCC 9+ inlined strcmp causes "Conditional jump or move depends on
uninitialised value" report'.
Patch from Mike Crowe <mac@mcrowe.com>.
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.
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.
https://bugs.kde.org/show_bug.cgi?id=434035
It has been observed that clang emits an error in valgrind.h for the macro
VALGRIND_DO_CLIENT_REQUEST_EXPR:
"[...] unsupported inline asm: input with type 'int' matching output with
type 'volatile unsigned long'"
Fix this with an explicit cast of the input to 'unsigned long int.'
The patch has been suggested by Jonathan Albrecht.
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).
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.
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.
https://bugs.kde.org/show_bug.cgi?id=433898
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.
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.
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.
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.
https://bugs.kde.org/show_bug.cgi?id=430158
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.
https://bugs.kde.org/show_bug.cgi?id=433641
vglibdir is the directory from where valgrind loads its internal tool
executables and vgpreloads. Currently vglibdir is pkglibdir, so those
internal tools are intermingeled with normal executables and libraries
that the user might use directly.
Make vglibdir equal to pkglibexecdir so the internal tools get installed
and loaded from libexec and don't get get stored under lib.
This leaves just the static archives and the mpiwrapper libraries that
the user would link/load themselves under pkglibdir.
This seems more in line with the FHS lib/libexec standard and makes it
slightly easier to combine the tools from a multilib target (say the
memcheck-amd64-linux and memcheck-x86-linux tools) because they would
be installed under the same directory, while the pkglibdir can differ
depending on arch/target (lib/lib64).
https://bugs.kde.org/show_bug.cgi?id=433323
