* print the output 64-bit results in most-to-least-significant
lane format
* change the memory values used in these tests to ones which
are reliably able to detect confusion of 8-bit lanes. The
previous values couldn't to that reliable. This change causes
the diff to be huge because the stdout.exp changes a lot.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13374
Reading header length and values in external line info was incorrect at
some places as it used offsets based on dw64 that came from .debug_info.
Instead, offsets should be calculated based on is64 from .debug_line.
This issue surfaced in MIPS64 port, and it was discussed at:
https://bugs.kde.org/show_bug.cgi?id=313267#c20
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13373
it easier to sync with stderr output. Also, add some more helpful
data for testing Neon loads/stores.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13372
Explicitly test together with -static -nodefaultlibs -nostartfiles to mimic
what the tools linking script does. At least on s390 the test might fail for
a non-static AC_LINK, while it does work when using those other flags too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13371
Bug #305513. We should only read the first DIE of a compilation unit.
Each compilation unit header is followed by a single DW_TAG_compile_unit
(or DW_TAG_partial_unit, but those aren't important here) and its children.
There is no reason to read any of the children at this point. If the first
DIE isn't a DW_TAG_compile_unit we are done, none of the child DIEs will
provide any useful information.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13369
Bug #305513 contained a patch for some extra robustness checks. But
the real cause of crashing in the read_unitinfo_dwarf2 DWARF reader
seemed to have been this issue where DWARF version 2 DWZ partial_units
were read and DW_FORM_ref_addr had an unexpected size. This combination
is rare. DWARF version 4 is the current default version of GCC.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13367
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
MIPS uses different values for socket types.
This is protected by ARCH_HAS_SOCKET_TYPES in Linux kernel and we introduce
it here too. This is important for log-socket feature, and it resolves the
issue reported in https://bugs.kde.org/show_bug.cgi?id=313267#c21.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13359
Enable wrappers on mips64 for the following calls:
- dup3
- accept4
- epoll_create1
- timerfd_settime
- newfstatat
Also, allow additional flock64 values in sys_fcntl for mips64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13358
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
