Patch to improve SSE/SS2 support
This patch should implement most of the missing SSE/SSE2 opcodes. About
the only ones it doesn't do are the MASKMOVxxx ones as they are quite
horrible and involved an implicit reference to EDI so I need to think
about them a bit more.
The patch also includes a set of tests for the MMX/SSE/SSE2 opcodes to
validate that they have the same effect under valgrind as they do when
run normally. In one or two cases this wasn't actually the case even
for some of the implemented opcodes, so I fixed those as well ;-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2202
remove the test that the first page of memory is inaccessible. This
is now getting in the way.
Fixes#69886.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2180
--branchpred=yes. I'm interested to know if these make a significant
difference for anyone - I see a small speed increase on the Pentium M.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2126
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
choosing the longest symbol, choose the longest ignoring any of the libc
junk prefixes like __libc_, __, __GI_*, etc. This makes the symbol
presented to the user in messages and used in *.supp files more consistent
and comprehensible.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2114
they rely on this area being unmapped for their quick sanity check. This
commit make Valgrind refuse to mmap() this area. Added a regtest for it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2085
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2027
indented one space; previously it was mixed, but Memcheck/Addrcheck indented
"Address" lines 3, which made them hard to see in the stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2021
option --show-below-main is on. It's on by default. It also affects
suppressions generated with --gen-suppressions=yes. Updated reg tests
accordingly.
Also updated docs for this. And added some missing command-line args to docs.
Also compartmentalised the options a little in the docs, and rearranged the
order of options in the usage message, in anticipation of a bigger
rearrangement that will be necessary soon -- to distinguish options used by all
skins from those used by error-checking skins, to skin-specific ones.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2020
bytes longs, when it could be shorter, which could cause false positives.
Added an example of this to the regtest.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1983
Scientific Library (gsl-1.4) compiled with Intel Icc 7.1 20030307Z '-g
-O -xW'. I think this gives pretty good coverage of SSE/SSE2 floating
point instructions, or at least the subset emitted by Icc. So far
tested on memcheck and nulgrind; addrcheck and cachesim still testing.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1955
can treat it like add and generate partially-defined results of multiply
with partially defined arguments. It may also speed things up a bit,
if they use lots of multiplies.
This change only deals with signed "new style" multiplies. That the x86
has two quite different kinds of multiply instructions: the "old-style"
signed and unsigned multiply which uses fixed registers (eax:edx) and
generates a result twice the size of the arguments, and the newer signed
multiple which takes general addressing modes. It seems that gcc always
(almost always?) generates the new signed multiply instructions, except
for byte-sized multiplies.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1925
to inline. This is needed to get a warning-free compilation on 3.3.1.
It seems we had "inline" on some pretty huge functions in places.
Also it appears gcc-3.3.1 won't inline a function call in a tail call
position, reasonably enough. I assume in that case it prefers to
create a tailcall to the callee, rather than inlining it.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1907
operator new(unsigned, std::nothrow_t const&)
operator new[](unsigned, std::nothrow_t const&)
because they weren't being intercepted, and called malloc(), which caused bogus
mismatch errors.
Added a regression test for it, too.
MERGE TO STABLE (although the change to vg_replace_malloc.c won't quite be a
cut and paste job, because of prior changes made to it in the head
but not the stable branch; merge will still be easy, though)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1899
valgrind.h. Although these requests are not implemented by the core, they can
be implemented by skins that track heap blocks, eg. Memcheck, Annelid, Massif.
This is in preparation for committing Massif to the repository.
I think I managed to make the change in a binary-compatible way. The only
inconvenience for users is that if they have a client program compiled with the
old requests in, Valgrind will abort with an explanatory message that tells
them to recompile. Once they've done that (no changes to their program are
required), it works again.
I even updated the docs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1881
requests from the Memcheck requests and putting the descriptions in the
appropriate parts of the docs.
Removed the __VALGRIND_SOME_SKIN_H test -- it was designed to prevent people
#including valgrind.h when they probably want memcheck.h, but it's actually a
reasonable thing to do to #include valgrind.h alone, because there are some
requests in valgrind.h.
Removed references to VALGRIND_MAKE_NOACCESS_STACK from the docs, as it doesn't
exist in the implementation.
Fixed a few other minor things.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1880
don't just call the unmangled versions, but do the appropriate stuff
themselves directly (this was necessary for Massif). This means that stack
traces for them have one fewer function. And I was able to gather up several
very similar functions into a macro, reducing the amount of code, which was
nice. Had to update one regtest's expected output accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1875
them in a shared place. (They used to be different, when Addrcheck didn't
distinguish between reads and writes, but now they're the same.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1837
Fixed now.
MERGE TO STABLE (assuming that Addrcheck does overlap checking in STABLE, which
I think it does)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1828
was just saying "invalid memory access").
Added a regression test for this, for memcheck and addrcheck. Also made
Addrcheck use Memcheck's fprw regtest. Was able to remove the not-very-useful
'true' test for Addrcheck now that it has a couple of real tests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1815
