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
type STT_GNU_IFUNC which, instead of pointing directly at the
function, point at a routine which will return the address of
the real function. Redirection of indirect functions is handled
by valgrind as follows:
- When a redirection specification matches an indirect
function symbol an active redirection is added in the
normal way, but with the isIFunc flag set.
- When a call is made to an address which matches an
active redirection with the isIFunc flag set the call
is redirected, but not to the target address of the
redirection - instead it is sent to a small wrapper
routine that is preloaded into the client.
- The wrapper routine calls the original client routine
and collects the result, which it reports to valgrind
using a client request, and then returns the result to
the caller.
- When valgrind gets the client request it looks up the
active redirection for the indirect function and then
adds a new active redirection which redirects from the
address returned by the indirection function to the
redirection target. This new redirection does not have
the isIFunc flag set so behaves as a normal redirection.
In addition to the above we also add a few new redirections to
memcheck to capture internal calls made by glibc to things like
strlen, as these internal calls do not go through the indirect
function and instead go direct to the chosen implementation.
Based on a patch from Dodji Seketeli and comments from Jakub
Jelinek, this commit closes bug 206013.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10920
