Necessary changes to support nanoMIPS on Linux.
Part 3/4 - Coregrind and tools changes
Patch by Aleksandar Rikalo, Dimitrije Nikolic, Tamara Vlahovic,
Nikola Milutinovic and Aleksandra Karadzic.
Related KDE issue: #400872.
The loop scenario:
The main thread sends a signal 15 to another thread, and then calls the exit syscall.
The exit syscall done by thread 1 marks all threads as needing
to die using exitreason VgSrc_ExitProcess.
The main thread then gets all other threads out of their blocking syscall
to let them die, and then "busy polls" for all other threads to disappear.
However, when the second thread is out of its syscall, it gets the signal 15,
which is a fatal signal. This second thread then changes the exit reason
of all threads to VgSrc_FatalSig, and itself starts to busy poll for all
other threads to disappear.
This then loops forever.
The fix for this consists in not handling the fatal signal in the
second thread when the process is already busy dying. Effectively,
the exit syscall should be processed "atomically": either the process
is running, or it is dead once the syscall is done.
Under valgrind, when threads are marked as being ' VgSrc_ExitProcess',
the guest process should be considered as dead. Valgrind has still to do
the cleanup, the endof run report, etc but otherwise should not let
any more user code to run. So, signal should not be handled anymore
once the 'exit syscall' has marked all threads as VgSrc_ExitProcess.
The hang scenario:
The main thread sends a signal 9 (KILL) to itself.
When running natively, this directly kills the process,
without giving any opportunity to run some user code.
Valgrind intercepts the kill syscall, and detects that this is
a fatal signal. The main thread was then dying, but was
not getting the other threads out of their syscall (to let them die).
The fix for this is to have the 'handling' of the signal 9 sent to a
thread of the process to directly make the process die, by getting
all threads out of syscall.
Note that the previous code was trying to have this action done by
the thread to which the signal 9 was sent. This was too tricky to
keep (causing other race conditions between the main thread sending
the signal 9 e.g. exiting and the other thread supposed to die).
As it is not particularly critical to have the signal 9 'handled'
by a specific thread, the thread that is sending the signal 9 is
the one doing the work to cleanup and terminate the process.
This implements minimal support for the pkey_alloc, pkey_free and
pkey_mprotect syscalls. pkey_alloc will simply indicate that pkeys
are not supported. pkey_free always fails. pkey_mprotect works just
like mprotect if the special pkey -1 is provided.
https://bugs.kde.org/show_bug.cgi?id=408091
Sync VEX/LICENSE.GPL with top-level COPYING file. We used 3 different
addresses for writing to the FSF to receive a copy of the GPL. Replace
all different variants with an URL <http://www.gnu.org/licenses/>.
The following files might still have some slightly different (L)GPL
copyright notice because they were derived from other programs:
- files under coregrind/m_demangle which come from libiberty:
cplus-dem.c, d-demangle.c, demangle.h, rust-demangle.c,
safe-ctype.c and safe-ctype.h
- coregrind/m_demangle/dyn-string.[hc] derived from GCC.
- coregrind/m_demangle/ansidecl.h derived from glibc.
- VEX files for FMA detived from glibc:
host_generic_maddf.h and host_generic_maddf.c
- files under coregrin/m_debuginfo derived from LZO:
lzoconf.h, lzodefs.h, minilzo-inl.c and minilzo.h
- files under coregrind/m_gdbserver detived from GDB:
gdb/signals.h, inferiors.c, regcache.c, regcache.h,
regdef.h, remote-utils.c, server.c, server.h, signals.c,
target.c, target.h and utils.c
Plus the following test files:
- none/tests/ppc32/testVMX.c derived from testVMX.
- ppc tests derived from QEMU: jm-insns.c, ppc64_helpers.h
and test_isa_3_0.c
- tests derived from bzip2 (with embedded GPL text in code):
hackedbz2.c, origin5-bz2.c, varinfo6.c
- tests detived from glibc: str_tester.c, pth_atfork1.c
- test detived from GCC libgomp: tc17_sembar.c
- performance tests derived from bzip2 or tinycc (with embedded GPL
text in code): bz2.c, test_input_for_tinycc.c and tinycc.c
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.
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.
be printed only once, rather than every time it happens. Also make it
not be printed in silent mode (-q).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16407
For fadvise64 system call, 7th 32-bit argument slot (third on the stack)
will also be used due to MIPS O32 calling convention in passing 64-bit
values.
sys_fadvise64(int fd, loff_t offset, loff_t len, int advice);
NR_fadvise64 -> v0 (sysno)
fd -> a0 (ARG1)
offset -> a2, a3 (ARG3, ARG4)
len -> SP + 16, SP + 20 (ARG5, ARG6)
advise -> SP + 24 (ARG7)
Change the code according to it.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16162
* Use stack arrays instead of malloc/free
* ensure msghdr_foreachfield does one single call to foreach_func
for consecutive fields
* some small code reformatting or factorisation
Tested on linux, hoping it also works on solaris
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16111
Also stop checking when max length of bytes have been reached.
Bug #369359
Found by LTP testcases/kernel/syscalls/recvmsg/recvmsg01.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15991
Don't do any more checks if it isn't safe to inspect the address family.
Likewise, don't check sun_path if the string address isn't safe.
Found by LTP testcases/kernel/syscalls/bind/bind01.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15990
The msg telling brk cannot be extended confuses some users
so improve the documentation and have the msg referencing the doc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15880
We were using some wrong syscall numbers in vki-scnums-arm64-linux.h
arm64 doesn't implement a couple of old deprecated system calls like
rename, dup2, getpgrp and fork. Adjust m_libcfile.c rename and dup2
functions to use renameat (also on tilegx) and dup3 (with fcntl fallback
for bad oldfd). And in m_libcproc.c implement getpgrp as getpgid(0).
Also don't compile the fork syswrap on arm64 (it only supports clone).
In practice this only affected callgrind which was unable to rename
dump files in some cases and ELF core dumps might have contained some
bogus prstatus fields.
Related to bug #359503 - Add missing syscalls for aarch64 (arm64)
Reported by Marcin Juszkiewicz who also posted a nice overview
of system calls on different linux architectures:
https://marcin.juszkiewicz.com.pl/2016/03/05/from-a-diary-of-aarch64-porter-system-calls/
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15824
We used to set the process datasize rlimit to zero to prevent
any internal use of brk() from having any effect. But later
linux kernels redefine RLIMIT_DATA as the size of any data
areas, including some dynamic mmap memory allocations.
See bug #357833 for the commit that went into linux 4.5
changing the definition of RLIMIT_DATA. So don't mess with
RLIMIT_DATA anymore. Just remember it for use in the syscall
wrappers.
This also cleans up some hacks around the execv and spawn wrappers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15766
This is a follow up to r14682:
When an mmap retry is done without any constraints, the kernel can
place it into free or reservation segments (i.e. anywhere there is no
mapping yet).
In r14682 a sanity check made the hypothesis that the new mapping was
in a free segment, but it does not hold at least on Linux 3.12 and 3.16
on amd64 (tested under Debian).
There is no risk in allowing the mapping to end up in (what was
previously) a reservation at this point, because it is also allowed.
Patch by Guillaume Knispel <xilun0@gmail.com>. Fixes BZ #348269.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15538
324181 was previously closed with a solution to always make
MAP_32BIT fail. This is technically correct/according to the doc,
but is not very usable.
This patch ensures that MAP_32BIT mmap is succesful, as long as
aspacemgr gives a range in the first 2GB
(so, compared to a native run, MAP_32BIT will fail much more quickly
as aspacemgr does not reserve the address space below 2GB on a 64 bits).
Far to be perfect, but this is better than nothing.
Added a regression test that test succesful mmap 32 bits till
the 2GB limit is reached.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15341
Here's why:
The condition
if (VG_(brk_limit) > VG_(brk_base)) line 1223
is reachable iff
newbrk < VG_(brk_base) on line 1201 is false AND
newbrk < VG_(brk_limit) on line 1205 is true
Rewrite as
newbrk >= VG_(brk_base) is true AND
newbrk < VG_(brk_limit) is true
Rewrite as
newbrk >= VG_(brk_base) is true AND
newbrk <= VG_(brk_limit) - 1 is true
Combine
VG_(brk_base) <= newbrk <= VG_(brk_limit) - 1
Therefore
VG_(brk_base) <= VG_(brk_limit) - 1
Or
VG_(brk_base) < VG_(brk_limit)
Which is the same as
VG_(brk_limit) > VG_(brk_base)
qed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15181
Mark 2 additional syscalls as 'mayblock' when fuse-compatible hint
is given.
Patch from aozgovde@ralota.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15112
- remove redundant asserts
- let VG_(am_extend_into_adjacent_reservation_client) worry about
- whether delta is too large
- whether the segment abutting this one exists and is a reservation
segment
The function already checks these things. No need to do it again here.
- do_brk does not need to know that a reservation segment must not
shrink beyond a single page. That detail ought to be hidden in
the address space manager.
Also, turn a few conditions into asserts.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14967
- Tighten up on asserts
- Simplify; as the function grows memory into a free segment, there
cannot possibly be any translations to be discarded. Free segments
do not have translations. sane_NSegment will make sure.
- Change the prototype to take in the start address of the mapping and
return a pointer to the resized segment. Previously, the code
ok = VG_(am_extend_map_client)( &d, old_seg, needL );
if (!ok)
goto eNOMEM;
VG_TRACK( new_mem_mmap, needA, needL,
old_seg->hasR, old_seg->hasW, old_seg->hasX,
was examining old_seg->hasR etc even though VG_(am_extend_map_client)
stated that *old_seg was invalid after the function returned.
That wasn't exactly a problem, but clearly looked wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14963
arm64, like amd64, must not use VKI_IPC_64, even
if this symbol is defined.
This makes the shmctl fail, which results in a zero size returned,
which means that the succesful shmat is not reported to the aspacemgr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14821
are always false. I'm keeping them as assertions for documentation purposes.
The proof is left as exercise to the reader.
Hint: use conditions on lines 307 and 311 and the fact that old_len and
old_arg are both unsigned entities.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14778
Learning aspacemgr to handle huge page is too difficult.
So, huge page requests that fails due to bad advice by aspacemgr
will (we hope) succeed if a mmap retry is done with the kernel,
without any constraints.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14682
Change VG_(resolve_filename) to not truncate the result which is returned
in a static buffer now. Fix callsites.
Simplify VG_(di_notify_pdb_debuginfo) to use VG_(resolve_filename).
Fix VG_(readlink) prototype.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14628
