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
both wrapped up in XML tags (as before) but also in plain text in a
sequence of CDATA blocks. Normally only one, but in the worst case
the raw data will have ]]> in it, in which case it needs to be split
across two CDATA blocks.
This apparently simple change involved a lot of refactoring of the
suppression printing machinery:
* in the core-tool iface, change "print_extra_suppression_info" (which
prints any auxiliary info) to "get_extra_suppression_info", which
parks the text in a caller-supplied buffer. Adjust tools to match.
* VG_(apply_StackTrace): accept a void* argument, which is passed to
each invokation of the functional parameter (a poor man's closure
implementation).
* move PRINTF_CHECK into put_tool_basics.h, where it should have been
all along
* move private printf-into-an-XArray-of-character functions from
m_debuginfo into m_xarray, and make them public
* gen_suppression itself: use all the above changes. Basically we
always generate the plaintext version into an XArray. In text mode
that's just printed. In XML mode, we print the XMLery as before,
but the plaintext version is dumped into a CDATA block too.
* update the Protocol 4 specification to match all this.
This still isn't 100% right in the sense that the CDATA block data
needs to be split across multiple blocks if it should ever contain the
CDATA end mark "]]>". The Protocol 4 spec has this right even though
the implementation currently doesn't.
Fixes#191189.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10822
of regression tests about intentionally uninitialized variables and
about intentionally freed non-heap memory.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10794
syscalls I've had the displeasure of encountering. Due to its
ridiculousness, the wrapper misses a PRE_MEM_WRITE check and so can result
in false positives. The POST_MEM_WRITE update is present, though, so it
shouldn't cause subsequent problems. Fixes bug 200760.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10786
- Always print a blank line after significant messages (eg. errors). This
makes the handling of blank lines much simpler.
- Don't print full stops at the end of messages. We mostly don't do it, so
I got rid of all the remaining ones I could find for consistency.
- Use --leak-check=full rather than --leak-check=yes, for consistency with
docs and other messages.
- Update partiallydefinedeq.stderr.exp2 for older changes.
This commit only updates the code. Test updates will follow shortly. (I'm
separating them so the code changes aren't swamped by the test changes in
the SVN logs.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10783
