GCC on RHEL 7.6 ARM complains about the empty init list.
I also noticed that we are using the SA_NOTIFY form of sigaction
(with that union member and handler prototype) but not setting the
SA_NOTIFY flag. Seems harmless in this case as we don't use
the siginfo or context.
cppcheck spotted a bug in the skipping of whitespace between shebang
and interpreter command. This could potentially cause the platform
to be misidentified (for x86 on amd64).
There was some code to handle /proc/curproc/file (a symlink to
the exe that wee need to bodge as it refers to the tool exe).
But it was neither tested nor working.
Can't use the same technique as Linux and Solaris which have more
complete /proc filesystems where each pid has symlinks for
each open file, which we use for the guest. Instead need to
copy the path ourselves. So move sys_readlink out of generic.
Simplify the handling of the resolved guest exe name - store it in
a global like VG_(args_the_exename).
bug464969_d_demangle depends on producing an error about an
uninitialized variable. But it prints something different
to stdout based on the value of that variable. Which can
produce failures. Make sure to always print the same thing
to stdout.
pth_mutex_signal.c:50:13: error: use of undeclared identifier 'SIGRTMAX'
sigaction(NATIVE_IO_INTERRUPT_SIGNAL, &signalAction, NULL);
Put this target under a condition for the moment.
AM_PROG_CC_C_O has been obsolete since automake 1.14.
AC_PROG_CC does the same check. With autoconf 2.70 we
must use AC_PROG_CC (which will check for c11 and c99),
for earlier versions we'll use AC_PROG_CC_C99.
This was being copied from the host. Now it's synthesized for
the guest. Also improve the none/freebsd/auxv test to
print a few of the strings in auxv (but not the envp ones).
On FreeBSD, Firefox uses the kern.proc.pathname.PID sysctl
to get the binary path (where PID can be the actual pid
or -1). The user path is /usr/local/bin/firefox which is
a symlink to /usr/local/lib/firefox/firefox.
This was failing because we were not handling this MIB.
That meant that the sysctl returned the path for the
binary of the running tool (e.g.,
/home/paulf/scratch/valgrind/memcheck/memcheck-amd64-freebsd).
Firefox looks for files in the same directory.
Since it was the wrong directory it failed to find them and
exited.
I also noticed a lot of _umtx_op errors. On analysis they
are spurious. The wake ops take an "obj" argument, a pointer
to a variable. They only use the address as a key for
lookups and don't read the contents.
The warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf3 isn't
very helpful. This means we didn't handle DW_OP_GNU_entry_value.
DW_OP_GNU_entry_value (or DWARF5 DW_OP_entry_value) means interpreting
the given DWARF expression using register values as they were upon
entering the function. Which is non-trivial to implement.
We can fail the evaluation of the DWARF expression without warning
about it by default, since it isn't really needed for any current
valgrind functionality (and it is only done with --read-var-info=yes.
Several issues with vector floating point instructions have gone unnoticed
due to a lack of test coverage in this area. Add a test case that
improves the coverage, particuarly when dealing with short and extended
floating point formats.
When trying to execute any of the vector float multiply-and-add family
instructions, Valgrind panics with the message "Iex_Qop with F128 data".
So far all F128 operations were implemented with instructions that operate
on FP register pairs. However, such instructions don't exist for
Iop_MAddF128 and Iop_MSubF128, so they must be implemented with vector
instructions instead. This was missed when emitting them in
"guest_s390_toIR.c".
Add the missing support. This also involves adding a few new features to
host_s390_defs:
* a new vector operation S390_VEC_INIT_FROM_FPRS
* the capability to move the left half of a VR to an FPR
* S390_VEC_FLOAT_MADD/_MSUB for 128-bit sizes
