Julian Seward [Sun, 19 Aug 2018 07:18:20 +0000 (09:18 +0200)]
arm64 front end: add early-writeback handling for w (32 bit int) and q (128 bit) stores.
Clang 6.0.1 creates instructions of the form str wX, [sp,#-N] and str qX,
[sp,#-N], and the lack of early writeback causes many false positive errors
from Memcheck, plus it potentially breaks the segfault-based main-thread stack
extension mechanism. This commit adds support for them, using the same scheme
with which existing cases are handled.
Julian Seward [Fri, 17 Aug 2018 07:31:37 +0000 (09:31 +0200)]
Fix 388174 - valgrind with Wine quits with "Assertion 'cfsi_fits' failed"
In check_CFSI_related_invariants, this commit improves the check for invariant
(2), which, as noted in an existing comment, "might need to be improved".
Instead of assuming that the CFSI range fits entirely into one "rx" mapping,
check that it is covered by the union of all the "rx" mappings we have. This
is the correct check. The previous check was observed to have failed as below
for at least some Clang generated objects (possibly in conjunction with lld as
the linker.)
Julian Seward [Fri, 17 Aug 2018 07:09:21 +0000 (09:09 +0200)]
Add changes to ensure that a DebugInfo that has been archived cannot be archived again.
* discard_or_archive_marked_DebugInfos: clear the mark bit for a Debuginfo
that will be archived
* discard_DebugInfos_which_overlap_with: when selecting DebugInfos to be
discarded or archived, fix a mistake in which some mark bits wouldn't be
changed at all, meaning their "old" value was used to influence the current
operation.
These may (or may not) fix #393146; at the very least, they are somehow
related.
Add file descriptor tracking in wrappers for bpf system call
Support for the bpf system call was added in a previous commit, but
did not include tracking for file descriptors handled by the call.
Add checks and tracking for file descriptors. Check in PRE() wrapper
that all file descriptors (pointing to object such as eBPF programs or
maps, cgroups, or raw tracepoints) used by the system call are valid,
then add tracking in POST() wrapper for newly produced file descriptors.
As the file descriptors are not always processed in the same way by the
bpf call, add to the header file some additional definitions from bpf.h
that are necessary to sort out under what conditions descriptors should
be checked in the PRE() helper.
Fixes: 388786 - Support bpf syscall in amd64 Linux
Add support for bpf() Linux-specific system call on amd64 platform. The
bpf() syscall is used to handle eBPF objects (programs and maps), and
can be used for a number of operations. It takes three arguments:
- "cmd" is an integer encoding a subcommand to run. Available subcommand
include loading a new program, creating a map or updating its entries,
retrieving information about an eBPF object, and may others.
- "attr" is a pointer to an object of type union bpf_attr. This object
converts to a struct related to selected subcommand, and embeds the
various parameters used with this subcommand. Some of those parameters
are read by the kernel (example for an eBPF map lookup: the key of the
entry to lookup), others are written into (the value retrieved from
the map lookup).
- "attr_size" is the size of the object pointed by "attr".
Since the action performed by the kernel, and the way "attr" attributes
are processed depends on the subcommand in use, the PRE() and POST()
wrappers need to make the distinction as well. For each subcommand, mark
the attributes that are read or written.
For some map operations, the only way to infer the size of the memory
areas used for read or write operations seems to involve reading
from /proc/<pid>/fdinfo/<fd> in order to retrieve the size of keys
and values for this map.
The definitions of union bpf_attr and of other eBPF-related elements
required for adequately performing the checks were added to the Linux
header file.
Processing related to file descriptors is added in a follow-up patch.
Move pre_check for ASCII string out of PRE(sys_prctl)
The sys_prctl wrapper with PR_SET_NAME option reads an ASCII string passed
as its second argument. This string is supposed to be shorter than a given
limit. As the actual length of the string is unknown, the PRE() wrapper
performs a number of checks on it, including, in worst case, trying to
dereference it byte by byte.
To avoid re-implementing all this logic for other wrappers that could
need it, get the string processing out of the wrapper and move it to a
static function. Note that passing tid as an argument to the function is
required for macros PRE_MEM_RASCIIZ and PRE_MEM_READ to work properly.
Julian Seward [Tue, 14 Aug 2018 08:13:46 +0000 (10:13 +0200)]
VG_(di_notify_mmap): once we've read debuginfo for an object, ignore all further mappings. n-i-bz.
Once we've read debuginfo for an object, ignore all further mappings. If we
don't do that, applications that mmap in their own objects to inspect them for
whatever reason, will cause "irrelevant" mappings to be recorded in the
object's fsm.maps table. This can lead to serious problems later on.
This has become necessary because 64aa729bfae71561505a40c12755bd6b55bb3061 of
Thu Jul 12 2018 (the fix for bug 395682) started recording readonly segments
in the fsm.maps table, where before they were ignored.
This change removes backtrace line (posix_fadvise64.c) that is not always in
output of the failing test (fadvise64).
It fixes memcheck/tests/mips64/fadvise64 on MIPS64 platforms with glibc 2.27
or newer.
Mark Wielaard [Tue, 31 Jul 2018 13:32:43 +0000 (15:32 +0200)]
Bug 397012 - glibc ld.so uses arch_prctl on i386.
arch_prctl used to be amd64 only. But since linux 4.12 it is also
implemented for i386. And since glibc 2.28 ld.so will use it to see
if the cpu/kernel provides CET support.
To prevent seeing:
WARNING: unhandled x86-linux syscall: 384
You may be able to write your own handler.
Read the file README_MISSING_SYSCALL_OR_IOCTL.
Nevertheless we consider this a bug. Please report
it at http://valgrind.org/support/bug_reports.html.
on every program run under valgrind just make it explicitly
not implemented (ENOSYS). This is fine for the glibc usage.
It just indicates there is no CET support.
Probably not very critical, as very surely the process will die
shortly after, but better still clean the memory, as the code
was already doing some effort to free memory (e.g. VG_(free)(seg_starts);).
Note that when testing on debian 9/amd64, the resulting core dump
was not very usable (e.g. was not really showing what the guest threads
are doing). So, there must be a bug in the core dumping logic.
Fix segmentation violation caused by stack misalignment when vgdb use ptrace to force activate gdbserver
On amd64, on a big application, a vgdb call that wakes up the application
using ptrace fails unfrequently (we speak about one failure every few thousands vgdb calls).
The failure started to appear when valgrind was compiled with gcc 7.3 instead of gcc 6.4
After investigation:
* gcc 7.3 is using (more) sse instructions
* Such instructions imply to have a stack pointer aligned on 16 bytes.
* vgdb-invoker-ptrace.c 'ptrace' modification of the stack pointer was
not respecting the amd64 ABI convention to align on 16 bytes.
It was also not protecting the red zone (unclear if this could cause
the problem, but in any case, this ptrace logic is similar to a
signal handler, and cannot modify the redzone.
The fix consists in respecting the ABI.
Without the patch, segmentation violation due to an sse instruction
being executed with an address on the stack not aligned on 16 bytes,
happening something like every 5000 vgdb execution.
With the patch, 250_000 executions without problems.
Fix wrong stack range output by commit 7daa08611 (more info in scheduler state)
The stack base starts at the beginning of the protection page/zone,
so we need to add VG_STACK_GUARD_SZB to get the real lowest usable
byte.
As the VgStack is an opaque type, add a function in aspacemgr to
return the Addr of the first lowest usable byte.
Mark Wielaard [Mon, 30 Jul 2018 10:20:16 +0000 (12:20 +0200)]
Bug 396887 - arch_prctl should return EINVAL on unknown option.
Currently arch_prctl calls VG_(core_panic) when it sees an unknown
arch_prctl option which kills the process. glibc uses arch_prctl with
an (as yet) unknown option to see if the kernel supports CET. This
breaks any application running under valgrind on x86_64 with:
valgrind: the 'impossible' happened:
Unsupported arch_prctl option
Thread 1: status = VgTs_Runnable (lwpid 19934)
==19934== at 0x121A15: get_cet_status (cpu-features.c:28)
==19934== by 0x121A15: init_cpu_features (cpu-features.c:474)
==19934== by 0x121A15: dl_platform_init (dl-machine.h:228)
==19934== by 0x121A15: _dl_sysdep_start (dl-sysdep.c:231)
==19934== by 0x10A1D7: _dl_start_final (rtld.c:413)
==19934== by 0x10A1D7: _dl_start (rtld.c:520)
We already handle all known options. It would be better to do as the
kernel does and just return failure with EINVAL instead.
Give some more information in the scheduler information thread status
* In case a thread is executing a syscall, give the syscall no being
executed.
* Show the address range of the valgrind stack, similarly to the client
stack
Bug 385412 - s390x: new non-vector z13 instructions not implemented
Apart from instructions with vector operands, Valgrind does not implement the
additional z/Architecture instructions introduced with z13.
These are:
- load and zero rightmost byte (LZRF, LZRG);
- load logical and zero rightmost byte (LLZRGF);
- load halfword high immediate on condition (LOCHHI);
- load halfword immediate on condition (LOCHI, LOCGHI);
- load high on condition (LOCFHR, LOCFH);
- store high on condition (STOCFH);
- perform pseudorandom number operation (PPNO), with the functions
PPNO-Query and PPNO-SHA-512-DRNG;
- load count to block boundary (LCBB).
Patches from Vadim Barkov (vbrkov@gmail.com), with coordination, testing
and format cleanups from Andreas Arnez (arnez@linux.ibm.com).
Fix the test VPCMPESTRM_0x45_128 so that it doesn't depend on random junk in RAX and RDX.
This test fails sporadically (eg, on Fedora 27 with gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5))
because the tested instruction uses RAX and RDX as input, but the test framework doesn't
set them :-/, so the outcome basically depends on whatever junk the compiler left in those
registers beforehand. As a result of this, all previous uses of RAX in the test have
been changed to use RSI instead. n-i-bz.
Fix a few inconsistencies in formatting.
In particular, when an expression is split on several lines,
put the operators (e.g. && , ||, +, -, ...) at the beginning
of the new line : this seems to be more common
in the code, and is the coding convention used e.g. in gcc/gdb
(and incidently also at my work :)).
Carl Love [Mon, 25 Jun 2018 21:24:14 +0000 (16:24 -0500)]
Fix ppc32 results for test_isa_2_06_part3.c.
The ppc32 results were not updated when the xvnegsp instruction support
was added. Add the xvnegsp 32-bit results to
ppc/test_isa_2_06_part3.stdout.exp.
Petar Jovanovic [Thu, 21 Jun 2018 09:59:20 +0000 (11:59 +0200)]
Add processing of sized delete operators into filter_libc
C++14 introduces sized delete operators and Valgrind support is added
by 6ef6f73. In addition, stderr filter which is used by Regtest should
be able to recognize this particular form in error report (just like
the other kinds of delete operators) in order to provide uniform output.
Fixes memcheck/tests/mismatches failure on non C++14 builds.
Mark Wielaard [Mon, 18 Jun 2018 13:07:27 +0000 (15:07 +0200)]
Add workaround for arm64 AT_HWCAP on newer kernels. Bug KDE#381556.
Starting with linux 4.11 the kernel started to populate the AT_HWCAPS
auxv entry. And glibc 2.26 now uses this to see whether it can use the
mrs instruction and certain feature registers on arm64. Since these
are not supported under valgrind this causes an unhandled instruction
error. Workaround this for now my just clearing the AT_HWCAPS on arm64.
This should be fixed properly by someone with knowledge of what each
of the arm64 HWCAPS bits mean and which bits correspond to instructions
and registers supported by VEX or not.
https://bugs.kde.org/show_bug.cgi?id=381556
Petar Jovanovic [Thu, 14 Jun 2018 15:26:09 +0000 (15:26 +0000)]
mips64: add N32 ABI support
Adding MIPS N32 ABI support.
BZ issue - #345763.
Contributed and maintained by mulitple people over the years:
Crestez Dan Leonard, Maran Pakkirisamy, Dimitrije Nikolic,
Aleksandar Rikalo, Tamara Vlahovic.
Julian Seward [Thu, 31 May 2018 15:03:08 +0000 (17:03 +0200)]
arm64-linux: VG_(sigframe_destroy): restore int regs, PC and SP from the sigcontext previously presented to the handler. n-i-bz.
So as to correctly (well, less incorrectly) simulate handlers that change
register state in the sigcontext they are given in the expectation that the
change will take effect immediately upon the handler returning.
http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindIndex
page indicates to rather go to
https://kcachegrind.github.io/html/Home.html
so update the doc accordingly.
callgrind: fix setting call counter to zero if requested
We did not set the call cost counters in CLG_(zero_bbcc) to zero,
which gets called by requests to set counters to zero
- via client request
- when entering a function if configured so
- via gdb monitor command (used by callgrind_control -z)
Counters are also set to zero after they are dumped out to a file.
This does not use CLG_(zero_bbcc), and was doing the right thing.
Julian Seward [Sat, 5 May 2018 08:03:26 +0000 (10:03 +0200)]
emit_ARM64Instr: fix assertion failures associated with chaining patching (ARM64in_XDirect). n-i-bz.
This has happened because (I think!) this has never before been tested with
guest code addresses >= 2^48. This in turn means that this is the first
time that
p = imm64_to_ireg(p, /*x*/9, i->ARM64in.XDirect.dstGA);
has been called upon to emit a constant which is non-zero in all four 16-bit
chunks, so it generates 4 instructions rather than (at most, in all previous
runs) 3, and so the "how many insns at max" assertions failed. This commit
fixes the assertions.
Skip the phdrs when we have to search the shdrs. In separate
.debug files the phdrs might not be valid (they are a copy of
the main ELF file) and might trigger assertions when getting
image notes based on them.
Fix 393023 - callgrind_control risks using the wrong vgdb
Search for a vgdb executable in the same dir as callgrind_control perl file.
If not found, search for a vgdb executable in a sibling coregrind dir
(covers the case of : perl callgrind/callgrind_control)
Otherwise, just hope we find a vgdb executable in PATH
Carl Love [Wed, 11 Apr 2018 19:03:29 +0000 (14:03 -0500)]
Fix 393017 - Add missing support for xsmaxcdp instruction, bug fixes for xsm
Missed the update to none/tests/ppc64/Makefile.am to remove the
expected output files test_isa_3_0_altivec.stdout.exp and
test_isa_3_0_other.stdout.exp.
Carl Love [Wed, 11 Apr 2018 17:51:21 +0000 (12:51 -0500)]
Fix 393017 - Add missing support for xsmaxcdp instruction, bug fixes for xsmincdp, lxssp, stxssp and stxvl instructions.
Add support for instruction xsmaxcdp in VEX/priv/guest_ppc_toIR.c.
Fixes in file VEX/priv/guest_ppc_toIR.c for xsmaxcdp, xsmincdp, lxssp,
stxssp and stxvl instructions.
Fix compiler issues with optimization option -O2 for test
none/tests/ppc64/test_isa_3_0.c.
Add test case test_xsmaxcdpi to test file none/tests/ppc64/test_isa_3_0.c.
Fixes to test none/tests/ppc64/test_isa_3_0.c for compiling inline functions
with optimization -O0. Assembly instruction fixes, test argument array size
fixes, max loop index fixes. Condition code register fixes to fix control
flow issues when compiled with optimization.
Update expected results for test_isa_3_0_altivec.stdout.exp-LE and
test_isa_3_0_other.stdout.exp-LE.
Petar Jovanovic [Tue, 10 Apr 2018 12:09:08 +0000 (14:09 +0200)]
Introduce RegWord type
On majority of architectures size of long matches register width.
On mips n32 size of long is 32 bits and register width is 64 bits.
Valgrind is written with assumption that long size matches register
width. This is the reason why both UWord for Valgrind and HWord for VEX
match size of long. Long size differs from register size on mips n32 ABI.
Introducing RegWord type that will match size of registers.
Part of the changes required for BZ issue - #345763.
Contributed by:
Tamara Vlahovic and Dimitrije Nikolic.
Petar Jovanovic [Wed, 4 Apr 2018 09:51:05 +0000 (11:51 +0200)]
mips64: use register numbers instead of aliases for inline assembly
There is an inconsistency in MIPS tools for N32/N64 related to register
aliases. To avoid ambiguity, use register numbers instead of aliases where
needed.
n-i-bz Fix possible stack trashing by semctl syscall wrapping
The modified test none/tests/sem crashes with a SEGV when valgrind is compiled
with lto on various amd64 platforms (debian/gcc 6.3, RHEL7/gcc 6.4,
Ubuntu/gcc 7.2)
The problem is that the vki_semid_ds buf is not what is expected by the kernel:
the kernel expects a bigger structure vki_semid64_ds (at least on
these platforms).
Getting the sem_nsems seems to work by chance, as sem_nsems is at
the same offset in both vki_semid_ds and vki_semid64_ds.
However, e.g. the ctime was not set properly after syscall return,
and 2 words after sem_nsems were set to 0 by the kernel, causing
the SEGV, as a spilled register became 0.
Fix consists in using the 64 bit version for __NR_semctl.
Tested on debian/amd64 and s390x.
Sometimes, at least on arm platforms, we get a stack trace with
only one function.
When this happens and massif removes the top fn, we end up trying
to create an execontext of 0 ips, as the only fn is removed,
and an execontext of 0 ips causes the assert in m_execontext.c
So, do whatever to avoid to crash when having a single fn stacktrace.
The whatever means use a null execontext, which is an execontext
of one single address 0x0.
Note that this is just to bypass the crash.
What is shown by massif is not very nice (but what could we show ?).
Note that instead of using such a null execontext, we could rather
just keep the single ips. But that might create a lot of single fn
entries in the xtree and/or show undesired functions.
So, we the null execontext, which is shown as 0xFFFFFFFFFFFFFFFF ???
in the massif output.
Tested on amd64 by artificially creating stacktrace of one fn.
Fix 338252 - building valgrind with -flto (link time optimisation) fails
* Addition of a new configure option --enable-lto=yes or --enable-lto=no
Default value is --enable-lto=no, as the build is significantly slower,
so is not appropriate for valgrind development : this should be used
only on buildbots and/or by packagers.
* Some files containins asm functions have to be compiled without lto:
coregrind/m_libcsetjmp.c
coregrind/m_main.c
If these are compiled with lto, that gives undefined symbols at link time.
The files to compile without lto are
coregrind/m_libcsetjmp.c
coregrind/m_main.c
To compile these files with other options, a noinst target lib is defined.
The objects of this library are then added to the libcoregrind.
* memcheck/mc_main.c : move the handwritten asm helpers to mc_main_asm.c.
This avoids undefined symbols on some toolchains. Due to this,
the preprocessor symbols that activate the fast or asm memcheck helpers
are moved to mc_include.h
Platforms with handwritten helpers will also have the memcheck primary
map defined non static.
* In VEX, auxprogs/genoffsets.c also has to be compiled without lto,
as the asm produced by the compiler is post-processed to produce
pub/libvex_guest_offsets.h. lto not producing asm means the generation
fails if we used -flto to compile this file.
* all the various Makefile*am are modified to use LTO_CFLAGS for
(most) targets. LTO_CFLAGS is empty when --enable-lto=no,
otherwise is set to the flags needed for gcc.
If --enable-lto=no, LTO_AR and LTO_RANLIB are the standard AR and RANLIB,
otherwise they are the lto capable versions (gcc-ar and gcc-ranlib).
* This has been tested on:
debian 9.4/gcc 6.3.0/amd64+x86
rhel 7.4/gcc 6.4.0/amd64
ubuntu 17.10/gcc 7.2.0/amd64+x86
fedora26/gcc 7.3.1/s390x
Bart Van Assche [Thu, 8 Mar 2018 20:57:41 +0000 (12:57 -0800)]
Linux: Add support for the zoned block device ioctls
Shingled magnetic recording drives support a command set called ZBC
(Zoned Block Commands). Two new ioctls have been added to the Linux
kernel to support such drives, namely VKI_BLKREPORTZONE and
VKI_BLKRESETZONE. Add support to Valgrind for these ioctls.
projects / thirdparty / valgrind.git / log
