PTRACE_GET_THREAD_AREA is not handled by amd64 linux syswrap, which leads
to false positive errors in 64 bits program ptrace-ing 32 bits processes.
For example, the below error was wrongly reported on GDB:
==25377== Conditional jump or move depends on uninitialised value(s)
==25377== at 0x8A1D7EC: td_thr_get_info (td_thr_get_info.c:35)
==25377== by 0x526819: thread_from_lwp(thread_info*, ptid_t) (linux-thread-db.c:417)
==25377== by 0x5281D4: thread_db_notice_clone(ptid_t, ptid_t) (linux-thread-db.c:442)
==25377== by 0x51773B: linux_handle_extended_wait(lwp_info*, int) (linux-nat.c:2027)
....
==25377== Uninitialised value was created by a stack allocation
==25377== at 0x69A360: x86_linux_get_thread_area(int, void*, unsigned int*) (x86-linux-nat.c:278)
Fix this by implementing PTRACE_GET|SET_THREAD_AREA on amd64.
When code uses utimensat with UTIME_NOW or UTIME_OMIT valgrind memcheck
would generate a warning. But as the utimensat manpage says:
If the tv_nsec field of one of the timespec structures has the special
value UTIME_NOW, then the corresponding file timestamp is set to the
current time. If the tv_nsec field of one of the timespec structures
has the special value UTIME_OMIT, then the corresponding file timestamp
is left unchanged. In both of these cases, the value of the corre‐
sponding tv_sec field is ignored.
So ignore the timespec tv_sec when tv_nsec is set to UTIME_NOW or
UTIME_OMIT.
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.
This patch makes sure that the process running under valgrind only sees
the AES, PMULL, SHA1, SHA2, CRC32, FP, and ASIMD features in auxv AT_HWCAPS.
https://bugs.kde.org/show_bug.cgi?id=381556
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.
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.
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.
Set correct values from Linux kernel.
See ./arch/mips/include/uapi/asm/sockios.h
This issue is covered by newly introduced memcheck test mips32/bad_sioc.
Reduces the number of compiler warnings on MIPS platforms.
Partial fix for BZ#370028.
Patch by: Aleksandar Rikalo <aleksandar.rikalo@imgtec.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16256
Fix 373192 Calling posix_spawn in glibc 2.24 completely broken
Functionally, this patch just does the following 2 changes to the
fork clone handling:
* It does not mask anymore CLONE_VFORK :
The only effect of this flag is to suspend the parent, waiting for
the child to either exit or execve.
If some applications depends on this synchronisation, better keep it,
as it will not harm to suspend the parent valgrind waiting for the
child valgrind to exit or execve.
* In case the guest calls the clone syscall providing a non zero client stack,
set the child guest SP after the syscall, before executing guest instructions.
Not setting the guest stack ptr was the source of the problem reported
in the bugs.
This also adds a test case none/tests/linux/clonev.
Before this patch, test gives a SEGV, which is fixed by the patch.
The patch is however a lot bigger : this fix was touching some (mostly
identical/duplicated) code in all the linux platforms.
So, the clone/fork code has been factorised as much as possible.
This removes about 1700 lines of code.
This has been tested on:
* amd64
* x86
* ppc64 be and le
* ppc32
* arm64
This has been compiled on but *not really tested* on:
* mips64 (not too clear how to properly build and run valgrind on gcc22)
It has *not* been compiled and *not* tested on:
* arm
* mips32
* tilegx
* darwin (normally, no impact)
* solaris (normally, no impact)
The changes are relatively mechanical, so it is not impossible that
it will compile and work out of the box on these platforms.
Otherwise, questions welcome.
A few points of interest:
* Some platforms did have a typedef void vki_modify_ldt_t,
and some platforms had no definition for this type at all.
To make it easier to factorise, for such platforms, the following has
been used:
typedef char vki_modify_ldt_t;
When the sizeof vki_modify_ldt_t is > 1, then the arg syscall is checked.
This is somewhat a hack, but was simplifying the factorisation.
* for mips32/mips64 and tilegx, there is a strange unconditional assignment
of 0 to a register (guest_r2 on mips, guest_r0 on tilegx).
Unclear what this is, in particular because this is assigned whatever
the result of the syscall (success or not).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16186
with no size/direction hints. (DVD_READ_STRUCT)
Patch from Austin English (austinenglish@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16153
with no size/direction hints. (CDROMSTOP).
Patch from Austin English (austinenglish@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16152
