Carl Love [Tue, 10 Sep 2013 19:01:00 +0000 (19:01 +0000)]
Bugzilla 323437, this is phase 2 in a series of patches adding support for IBM
Power ISA 2.07. The first bugzilla in the series was: 322294: Add initial
support for IBM Power ISA 2.07
Phase 2 VEX commit 2756 added support for the following new instructions to
VEX/priv/guest_ppc_toIR.c:
- lq, stq, lqarx, stqcx.
- mfvsrwz, mtvsrwz
- fmrgew, fmrgow
This commit adds the corresponding test cases for these instructions.
Carl Love [Fri, 6 Sep 2013 22:29:55 +0000 (22:29 +0000)]
The existing overflow detection in VEX/priv/guest_ppc_toIR.c/set_XER_OV_64()
under the case PPCG_FLAG_OP_MULLW: does not apply to the mulldo as we need to
detect overflow when performing a Multiply Low Doubleword (not Multiply Low
Word). Hence, we added a new enumeration value PPCG_FLAG_OP_MULLD in
VEX/priv/guest_ppc_defs.h and a corresponding new case under which the
computation for detecting overflow for mulldo/mulldo. is added in
set_XER_OV_64(). The tests have been added to: none/tests/ppc32/jm-insns.c
Carl Love [Thu, 5 Sep 2013 19:50:41 +0000 (19:50 +0000)]
The current VEX code is not properly handling a non-zero TH field in the
dcbt instruction, which is valid for several forms of data cache block
touch instructions. The VEX commit 2761 fixed the missing support in
VEX/priv/guest_ppc_toIR.c. This commit adds tests for the the non-zero
fields to the test cases for 32 and 64-bit modes.
Carl Love [Thu, 5 Sep 2013 17:59:03 +0000 (17:59 +0000)]
The flag for compiling test none/tests/ppc32/test_isa_2_07_part2.c was
incorrectly set to FLAG_M64 instead of FLAG_M32. Fixed the flag. The
issue was reported in Bugzilla 324546.
Fix 324514 gdbserver monitor cmd output behaviour consistency + allow user
to put a "marker" msg in process log output
* v.info n_errs_found accepts optional msg, added in the output of
the monitor command.
* use VG_(printf) rather than VG_(gdb_printf) when output of command
should be redirected according to v.set gdb_output|log_output|mixed_output
* also avoid calling gdb_printf in output sink processing
to output zero bytes, as gdb_printf expects to have a null terminated
string, which is not ensured when 0 bytes have to be output.
* some minor reformatting (replace char* xxx by char *xxx).
Add a bunch of suppressions for 64-bit OSX 10.8 processes. This is a
huge kludge in that the right fix is to write proper syscall wrappers
for the new threading syscalls in 10.8, but that hasn't happened yet.
Mark Wielaard [Tue, 3 Sep 2013 15:22:14 +0000 (15:22 +0000)]
Reuse (shared) cachegrind source files in callgrind directly.
The callgrind Makefile.am had a common sources list that included
../cachegrind/cg_arch.c. This doesn't play well with automake and
subdir-objects. Especially make distclean was broken because some
.deps files were removed multiple times.
Just include the shared source file directly into the callgrind
source file that needs it (cg_arch.c in sim.c).
Fixes and kludges (mostly the latter) needed to run graphical
apps on OSX 10.8:
* port_create_vanilla: deal with the fact that ports get looked
up before they get registered in the allocated_ports list. I
think this is a side effect of ..
add_mapping_callback on Darwin: also produce a ChangedSeg record in
the case where V's record of the permissions for a range differs from
that of the kernel's. The lack of this caused synthetic segfaults
("can't translate here") from m_translate on OSX 10.8 for pretty much
any graphical .
Florian Krohm [Sat, 31 Aug 2013 16:02:15 +0000 (16:02 +0000)]
s390: Fix Makefile.am. Essentially, revert r13317 which does not seem to
be necessary. The additional DIST_INSN_TESTS variable was causing problems
in check_makefile_consistecy which reported false errors. I suspect this
is because my awk is mawk and not gawk.
Also add dfp_utils.h which was missing in the tarball from 'make dist'.
Mark Wielaard [Tue, 27 Aug 2013 10:23:23 +0000 (10:23 +0000)]
Support mmxext (integer sse) subset on i386 (athlon). Bug #323713
Some processors like the AMD Athlon "Classic" support mmxext,
a sse1 subset. This subset is not properly detected by VEX.
The subset uses the same encoding as the sse1 instructions.
The subset is described at:
http://support.amd.com/us/Embedded_TechDocs/22466.pdf
https://en.wikipedia.org/wiki/3DNow!#3DNow.21_extensions
Detects mmxext subset from cpuid information (and enables it
when full sse1 is found). Also fixes the prereq of
none/tests/x86/insn_mmxext.vgtest so that it also runs when
full sse1 (and not just the mmxext subset) is found.
It already passed on such configurations. With the VEX patch
(r2745) it also passes with just the mmxext subset.
Dejan Jevtic [Thu, 22 Aug 2013 06:04:08 +0000 (06:04 +0000)]
mips32: Fix a problem with gdb invoker.
This patch fixes the endian issue with gdb invoker on mips32
big endian. Now we are using pointer to long long and
we don't need to sign extend registers. On mips32 o32 abi
we need to make extra stack space when we are calling
function.
Carl Love [Wed, 21 Aug 2013 19:47:19 +0000 (19:47 +0000)]
The file tests/ppc32/power_ISA2_05.stdout.exp_Without_FPPO was a link
to file tests/ppc64/power_ISA2_05.stdout.exp_Without_FPPO. That was a
commit error as the output for ppc32 and ppc64 are different. Replaced
the link with the correct real file of expected results. See bugzilla
81535.
Carl Love [Wed, 21 Aug 2013 19:46:50 +0000 (19:46 +0000)]
The file tests/ppc32/power_ISA2_05.stdout.exp_Without_FPPO was a link
to file tests/ppc64/power_ISA2_05.stdout.exp_Without_FPPO. That was a
commit error as the output for ppc32 and ppc64 are different. Remove
the file and commit to remove the link.
kludge to bypass inner valgrind mmap failing due to not observed outer mmap
Some tests are failing in an "outer/inner" setup with an "out of memory"
situation reported by the inner (e.g. memcheck/tests/err_disable4.vgtest).
Looks like this is because the inner valgrind aspacemgr believes
a segment is free and can be used, but segment is in fact used by the outer.
This can happen as the inner cannot observe the outer mmap, and so
inner aspacemgr can be out of sync with the kernel and the outer.
This kludge bypasses the problem: if the fixed mmap fails in the inner,
the inner retries without the fixed.
This is a kludge as the proper solution would be to have a correct
state of aspacemgr in the inner. This however implies a more in-depth surgery
in the outer/inner setup (to have e.g. the outer informing the inner of
its own mmap or alternatively having the inner asking the outer about the
mmap advisory).
Kludge is preferred (at least now) as this kludge is activated only
for the inner (and for darwin, but that was already like that).
Of course, this kludge does not the state of the inner aspacemgr
matching the outer and kernel state.
So, other problems might be detected e.g. if inner aspacemgr does a check
comparing its status with kernel status.
The patch also ensures the inner reports the memory status of the
outer (using a client request) when an out of memory situation is detected.
This helps understanding what goes wrong.
Carl Love [Mon, 12 Aug 2013 18:04:22 +0000 (18:04 +0000)]
Initial ISA 2.07 support for POWER8-tuned libc
The IBM Power ISA 2.07 has been published on power.org, and IBM's new POWER8
processor is under development to implement that ISA. This patch provides
initial runtime and testsuite support for running Valgrind on POWER8 systems
running a soon-to-be released Linux distribution. This Linux distro will
include a POWER8-tuned libc that uses a subset of the new instructions from
ISA 2.07. Since virtually all applications link with libc, it would be
impossible to run an application under Valgrind on this distro without adding
support for these new instructions to Valgrind, so that's the intent of this
patch. Note that applications built on this distro will *not* employ new POWER8
instructions by default. There are roughly 150 new instructions in the Power
ISA 2.07, including hardware transaction management (HTM). Support for these
new instructions (modulo the subset included in this bug) will be added to
Valgrind in a phased approach, similar to what we did for Power ISA 2.06.
Julian Seward [Mon, 12 Aug 2013 10:42:49 +0000 (10:42 +0000)]
Add test cases for 128-bit shadow loads with --partial-loads-ok={yes,no}
in such a way that they can be shared across targets that support 128 bit
loads, as required. amd64 only right now. Adds memcheck/tests/common
to hold this stuff. Bug #294285.
Carl Love [Fri, 9 Aug 2013 21:55:45 +0000 (21:55 +0000)]
The following instructions were introduced in the Power ISA 2.05
(i.e., POWER6) - lfdp - stfdp - lfdpx - stfdpx These instructions were promptly
deprecated (phased out) in ISA 2.06 (i.e., POWER7). Recent updates in binutils
no longer supports these instructions unless the assembler is invoked with
'-mpower6'. When 'make check' is run on valgrind when using such a newer
binutils and running on a ppc64 system newer than POWER6, you get the
following build error:
y
pc64_linux=1 -DVGPV_ppc64_linux_vanilla=1 -DVGA_SEC_ppc32=1 -DVGP_SEC_ppc64_linux=1 -Winline -Wall -Wshadow -g -Winline -Wall -Wshadow -g -I../../../include -m64 -Wno-long-long -Wwrite-strings -fno-stack-protector -Wno-write-strings -MT power_ISA2_05-power_ISA2_05.o -MD -MP -MF .deps/power_ISA2_05-power_ISA2_05.Tpo -c -o power_ISA2_05-power_ISA2_05.o `test -f 'power_ISA2_05.c' || echo './'`power_ISA2_05.c
/tmp/cciGIkGG.s:Assembler messages:
/tmp/cciGIkGG.s:387: Error: operand out of domain (31 is not a multiple of 4)
/tmp/cciGIkGG.s:387: Error: syntax error; found `,', expected `('
/tmp/cciGIkGG.s:387: Error: junk at end of line: `,9'
/tmp/cciGIkGG.s:478: Error: operand out of domain (31 is not a multiple of 4)
/tmp/cciGIkGG.s:478: Error: syntax error; found `,', expected `('
/tmp/cciGIkGG.s:478: Error: junk at end of line: `,9'
make[2]: *** [power_ISA2_05-power_ISA2_05.o] Error 1
make[2]: Leaving directory `/tmp/Valgrind_review/valgrind_ISA2_05/memcheck/tests/ppc64'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/tmp/Valgrind_review/valgrind_ISA2_05/memcheck/tests/ppc64' make: *** [check-recursive] Error 1
This patch fixes the problem by adding a configure check to determine if these
phased out instructions are supported by the binutils, and the result of that
configure check is used to decide whether or not to compile in the source for
testing these instructions.
Julian Seward [Thu, 8 Aug 2013 10:56:08 +0000 (10:56 +0000)]
A comprehensive test case for 128 bit shadow vector loads in the case
of partial addressibility, for --shadow-loads-ok=yes and =no. Not
portable and not hooked up to the test/build system yet.
Julian Seward [Thu, 8 Aug 2013 10:41:46 +0000 (10:41 +0000)]
Fix # 294285: --partial-loads-ok does not work for 16-byte SSE loads
(core fixes for the memcheck handling of 128 bit loads)
(Patrick J. LoPresti, lopresti@gmail.com)
fix --vgdb-prefix no / character interpreted differently by V gdbsrv and vgdb
When --vgdb-prefix contains no / character,
the Valgrind gdbsrv is interpreting the prefix value as the filename
prefix in the current directory, while vgdb interprets this as
a directory to be opened in the current directory.
Cbange vgdb.c so that it uses the same interpretation as V gdbsrv
Update configure machinery to detect PTRACE_GETREGS
Using #ifdef PTRACE_GETREGS gives difficulties as in some
platforms (e.g. mips) PTRACE_GETREGS is not defined as a
preprocessor symbols unless linux/ptrace.h is included.
However, including linux/ptrace.h causes compilation error on some
other platforms
=> better detect that PTRACE_GETREGS can be used using the
configure machinery.
This should make vgdb PTRACE_GETREGS working again on
various platforms (x86/amd64/mips/...) as PTRACE_GETREGS
was disabled on all of these following r13471
Bypass GDB bug which asks to read packet slightly too big
GDB sometimes asks slightly too big read packets
(no taking into account the packet overhead).
Bypass the problem by allocating slightly more than needed
if GDB would only ask the correct maximum size.
Include of linux/ptrace.h was added in revision r11740,
to avoid compilation error on s390x (fedora and suse).
The compilation error was retrieved thanks to archeological research
done by Christian Borntraeger: without this include, the following was given:
error: 'PT_ENDREGS' undeclared
There was also some errors on ppc64 around the same time:
error: 'PTRACE_GETREGS' undeclared
Currently, the inclusion of linux/ptrace.h gives a problem on amd64/fedora20:
/usr/include/linux/ptrace.h:58:8: error: redefinition of ‘struct ptrace_peeksiginfo_args’
/usr/include/sys/ptrace.h:191:8: note: originally defined here
According to man ptrace, it is good enough to include sys/ptrace.h
(which should avoid the problem on amd64/f20).
The linux/ptrace.h is deemed not necessary anymore as:
1. Christian has tested on sles11sp2 on s390x.
2. since linux/ptrace.h was added in vgdb.c, #ifdef PT_ENDREGS and
#ifdef PTRACE_GETREGS were added
=> remove the linux/ptrace.h
(tested on x86/f12, ppc64/f18, amd64/deb6, sles11sp2/s390x)
mips32: Add support for mips32 DSP instruction set.
Add support for mips32 DSP and DSP revision 2 ASE.
More details about the mips32 DSP(r2) ASE:
http://www.mips.com/media/files/MD00566-2B-MIPSDSP-QRC-01.00.pdf
Applied patch provided by Maja Gagic <maja.gagic@rt-rk.com>
fix incorrect lineno in supp error msgs+ -v give filename+lineno of used supp.
If a suppression file contains an error, the lineno reported could be wrong.
Also, give filename and lineno of the used suppressions in -v debugging output.
The fix consists in ensuring that tool specific read_extra function gets
the Int* lineno pointer, together with other VG_(get_line) parameters.
fix 321960 pthread_create() then alloca() causing invalid stack write errors
Problem created by a discrepancy between the initial main stack
anon segment, and the main stack registered in m_stacks.c
Looking at some tracing; we see that there are two pages of stack:
--9078:2:main tell tool about 0ffefff000-0fff000fff rw-
The stack between the base and the current sp is marked as not accessible:
--9078:2:main mark stack inaccessible 0ffefff000-0fff0004bf
This is matching the aspacemgr view:
--9078:1:aspacem 22: RSVN 0ffe801000-0ffeffefff8380416 ----- SmUpper
--9078:1:aspacem 23: anon 0ffefff000-0fff000fff 8192 rw---
(all the above is normal/as expected)
However, the main stack is registered in m_stacks.c as having only one page:
--9078:2:stacks register 0xFFF000000-0xFFF000FFF as stack 0
When the main stack is grown, m_stacks.c is informed by m_signals.c
that the stack is grown. This is done by trapping the signal 11
when a not mapped page is accessed.
However, the 2nd page does not cause a signal (as it is mapped).
So, m_stacks.c still believes the main has one page stack.
This then gives problems in the tracking of the SP and current_stack
in m_stacks.c.
Only one page was registered for the main stack, as the registration
was done with values computed before possibly adding a page
needed for the ABI redzone.
The fix is to properly register the main stack with the size of
the stack segment, once all aspects have been taken into account.
With the fix, the stack is registered as:
--31501:2:stacks register 0xFFEFFF000-0xFFF000FFF as stack 0
Another possible fix would be to always register the main stack with the
full size of the aspacemgr stack segment (i.e. the anon+RSVN above)
(idea is that this is similar to non main threads, for which the
full thread stack is registered from the beginning, even if not fully
used yet).
The first fix was preferred, assuming it is better to keep registering
the main stack "physical" size (and not its maximal size).
Test memcheck/tests/thread_alloca added, based on reproducer
done by Daniel Stodden.
The bug might be triggered or not depending on the initial value
of the SP, which is influenced by the size of the "env".
So, the test execs itself, growing each time the environment.
This has given a reasonable chance/way to reproduce the bug on Ubuntu 12
and on a Debian 6.
(tested on amd64/Ubuntu 12 and Debian 6
x86/fedora12
ppc64/fedora18
Note that while investigating this bug, another strange thing was seen:
thread stacks are registered in m_stacks.c but are never unregistered.
It is not very clear that it is needed or not to unregister them:
thread stack segments are not freed when a thread terminates :
when a thread slot is re-used, its thread stack will also be re-used.
(Is that good for address space mgt ? A process that has created many
temporary threads will have the thread stacks lost forever ???).
On MIPS64 address of 'undefined' can be 64-bit width.
When we are trying to access that address we need to use 0x%lx
instead of 0x%x.
Fixes gdbserver_tests/mcvabits for MIPS64.
Add a function in the memcheck/tests/leak-segv-jmp.c for MIPS64
that execute the syscall. Because we added the mips64 case we
need to change the line number in *.exp file.
Fixes memcheck/tests/leak-segv-jmp for MIPS64.
mips64: Correct the value for the VG_MIN_MALLOC_SZB
The VG_MIN_MALLOC_SZB was incorrectly defined for MIPS64.
The incorrect value was 8 and the correct value is 16.
Fixes massif/tests/big-alloc for MIPS64.
Petar Jovanovic [Sat, 13 Jul 2013 23:50:46 +0000 (23:50 +0000)]
mips32/mips64: Avoid breakpoints in branch delay slots
Reusing parts of Chris Dearman's change in GDB to avoid placing breakpoints
in a branch delay slot.
Fixes gdbserver_tests/mcbreak for MIPS32 and MIPS64.
Petar Jovanovic [Fri, 12 Jul 2013 15:32:27 +0000 (15:32 +0000)]
mips32: another VG_(am_get_advisory) needs non-single-page-size adjustment
Another mmap issue in which another VG_(am_get_advisory) needs adjustment
wrapper for cases when (VKI_SHMLBA > VKI_PAGE_SIZE) and argument is
VKI_MAP_SHARED.
Fix by DejanJ for Bug #320057.
Issue and the test case by Vasile Floroiu.
Add test cases pertaining to vex r2731, for the following instructions:
SSAX SXTAB16 SHASX SHSAX SHSUB16 SHSUB8
UASX USAX UQADD16 UQASX UQSAX UHASX UHSAX REVSH
projects / thirdparty / valgrind.git / log
