reachable, or from possibly reachable to definitely reachable, rescan
it so that any blocks it points to are also upgraded. Fixes#206600.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11395
zeroing out caller saves registers before the leak check. We should
really do this on all platforms, not just these.
(Maynard Johnson, maynardj@us.ibm.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11336
messages printed for client-annotated blocks do now include a correct
address description. Closes#237371.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11320
word copies whenever possible. This drastically reduces the number of
memory references Memcheck has to process and speeds up a test program
that does repeated memcpys of large blocks by a factor of 4 or more.
Also add a vectorised version of memset.
The memcpy version is also constructed with a view to be used in
exp-ptrcheck, so it can copy areas of memory without losing
pointer-identity shadow data, as happens when doing all copies at a
byte granularity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11288
glibc-2.11 when running on SSE4-enabled (virtual) CPUs, for the usual
reason: to avoid ultra-optimised routines using the SSE 4.2 PCMPxSTRx
instructions. I would not be surprised if it turned out that strspn
was required, but I haven't seen a need for it so far.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11268
* handle new pseudo-reg XMM16 in memcheck/mc_machine.c
* run_thread_for_a_while: assert that the amd64 XMM guest reg array
has no holes and the elements are the right size, so that the
(PCMP)ISTRI_* helpers can treat it as an array.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11249
messages now begin with "valgrind: ", and they're more often printed before
the preamble. This required introducing a new message kind, Vg_FailMsg, and
functions VG_(fmsg) and VG_(fmsg_bad_option), and removing
VG_(err_bad_option).
Where we used to have horrible output like this:
[ocean:~/grind/ws2] vg5 --tool=massif --threshold=101 date
==31877== Massif, a heap profiler
==31877== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote
==31877== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==31877== Command: date
==31877==
==31877== --threshold must be between 0.0 and 100.0
valgrind: Bad option '--threshold'; aborting.
valgrind: Use --help for more information.
We now have nice output like this:
[ocean:~/grind/ws2] vg2 --tool=massif --threshold=101 date
valgrind: Bad option: --threshold=101
valgrind: --threshold must be between 0.0 and 100.0
valgrind: Use --help for more information or consult the user manual.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11209
svn merge -r11143:HEAD svn://svn.valgrind.org/valgrind/branches/MACOSX106
There were some easy-to-resolve conflicts.
Then I had to fix up coregrind/link_tool_exe*.in -- those files had been
added independently on both the trunk and the branch, AFAICT. I just
overwrote the trunk versions with the branch versions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11194
executables. Gets rid of the linker script kludgery and uniformly
uses -Ttext=0x38000000 (or whatever) on Linux, so as to accomodate
both traditional ld and gold. Should fix#193413 although I have
been unable to test it. Using a whole new program seems like
overkill, but this is infrastructure to support static linking of
the tool executables on MacOS too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11141
of mmap. Fixes#205541 and its dup #210268. The fix is simple enough
but the analysis is a bit complex, as detailed in comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11031
floating point, since the softfloat results are way different from the
hardware one (not to mention, V reports lots of accesses-below-the-SP
in the softfloat helper functions.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10999
the changes to do with reading and using ELF and DWARF3 info.
This breaks all targets except amd64-linux and x86-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10982
