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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13491
(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.
Bugzilla 323116
committed by Carl Love, carll@us.ibm.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13490
of partial addressibility, for --shadow-loads-ok=yes and =no. Not
portable and not hooked up to the test/build system yet.
Pertains to #294285.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13489
(core fixes for the memcheck handling of 128 bit loads)
(Patrick J. LoPresti, lopresti@gmail.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13488
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>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13470
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13469
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-0ffeffefff 8380416 ----- 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 ???).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13467
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13456
in VEX r2727 (conversion ops between binary floating point and
decimal floating point).
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13428
Line numbers are off by one in some outputs since it differs on GCC version
how it will map source code to line number for the ternary operator written
in multiple lines.
This is small fix that replaces one occurrence of ternary operator with
if-then-else. The excepted outputs have been changed accordingly.
This fixes the test memcheck/tests/cond_ld_st for different platforms with
different GCC versions.
Tested on x86, i386, ARM, MIPS32, and MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13415
in case the field holds a 32-bit floating point value.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13413
Bug #320116. sockaddr_rc might contain some padding which might not be
initialized. Explicitly check the sockaddr_rc fields are set. That also
produces better diagnostics about which field is unitialized.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13404
This fixes:
- memcheck/tests/cond_ld and
- memcheck/tests/cond_st
for 32-bit non-ARM architectures. Tested on IA32 and MIPS32.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13401
the definedness check and possible shadow temp set-to-defined be
optional. Use this to properly instrument IRLoadG and IRStoreG, so
that if the load/store does not happen, not only is the validity of
the address not checked, neither is the definedness.
This fixes a regression introduced by the COMEM branch on ARM, in
which conditional loads/stores with addresses which are undefined at
runtime and with guards which are false, would generate false errors.
Also extensively re-checked the check-generation machinery and updated
a bunch of comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13386
The replacement functions are running on the simulated CPU.
The code on the simulated CPU does not necessarily use
all arguments. E.g. args can be ignored and/or only given
to a NON SIMD call.
The definedness of such 'unused' arguments will not be verified
by memcheck.
A call to 'trigger_memcheck_error_if_undefined' allows
memcheck to detect such errors for the otherwise unused args.
Apart of allowing memcheck to detect an error, the function
trigger_memcheck_error_if_undefined has no effect and
has a minimal cost for other tools replacing malloc functions.
(suggestion of the 'no operation check' from Julian).
tested on f12/x86, debian6/amd64, f18/ppc64
Note that some Darwin specific code has been modified
in coregrind/m_replace_malloc/vg_replace_malloc.c.
(Some of) this code has not been compiled (no access to a
Darwin system). The code changed is trivial, so there is
some chance it will compile and even maybe work.
Added a new test verifying that various malloc related
functions undefined args are triggering an error in memcheck.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13361
Add mips64-le implementation of:
- atomic_add_8bit
- atomic_add_16bit
- atomic_add_32bit
- atomic_add_64bit
- do_acasW
Minor fixes for mips32 implementations are included as well.
These functions are needed to execute atomic_incs and annotate_hbefore
tests on mips64le.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13357
memcheck/tests/vbit-test fails with unknown opcode after introduction
of new Iops for AVX2, BMI, FMA support #317506
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13347
(problem reported in bug 307082, comment 8).
Solution applied is similar to what is in 307082 patch
(i.e. do not destroy the internal helgrind var if nWaiters > 0).
But also do not remove it from the FM.
+ add a test case (re-using the drd test case)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13329
* when SEGV trapped, report the main thread size as an unsigned size_t
* Similar for memcheck overlap errors
For example, for the 2 calls:
memcpy(&a, &a, 2147483648UL);
memcpy(&a, &a, -1); // silently accepted by gcc 4.4.4 -Wall
// while the 3rd arg is supposed to be a size_t
we now obtain (on a 32 bit system)
Source and destination overlap in memcpy(0xbe97113f, 0xbe97113f, 2147483648)
Source and destination overlap in memcpy(0xbef6d13f, 0xbef6d13f, 4294967295)
instead of
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -2147483648)
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -1)
Do not ask me why
memcpy(&a, &a, -1);
is supposed to be accepted/acceptable/valid code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13326
* avoid a warning related to pointer types
* replace exit (0) by return 0 (might help backtraces on Darwin, suggestion by Rich Coe)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13301
Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292
Update vbit tester. Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ #307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13285
causing segfaults with gcc-4.7. The inline assembly still isn't right,
but it's better than it was before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13279
