look at whether the eflags are read or written and generate UCode to validate
and/or mark as valid the eflags when necessary.
CCMAIL: 78514-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2344
This patch adds translation tests for most of the basic x86 instructions and
fixes a few missing/broken instructions to work properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2242
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
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
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
a way consistent with the position of the register field in the
instruction. In Intel encoding parlance, the G register is in bits
5,4,3 and the E register is bits 2,1,0, and so we adopt this scheme
consistently. Considering how much confusion this has caused me in
this recent bout of SSE hacking, consistent renaming can only be a
good thing. It makes it a lot easier to figure out if parts of the
SSE handling machinery are correct, or not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1698
the same as that for FPU instructions. That is, regard the MMX state
(which is the same as the FPU state) opaquely, and every time we
need to do a MMX instruction, move the simulated MMX state into the
real CPU, do the instruction, and move it back. JeremyF's optimisation
to minimise FPU saves/restores applies automatically here.
So, this scheme is simple. It will cause memcheck to complain bitterly
if uninitialised data is copied through the MMX registers, in the same
way that memcheck complains if you move uninit data through the FPU
registers. Whether this turns out to be a problem remains to be seen.
Most instructions are done, and doing the rest is easy enough, I just
need people to send test cases so I can do them on demand.
(Core) UCode has been extended with 7 new uinstrs:
MMX1 MMX2 MMX3
-- 1/2/3 byte mmx insns, no references to
integer regs or memory, copy exactly to the output stream.
MMX_MemRd MMX_MemWr
-- 2 byte mmx insns which read/write memory and therefore need
to have an address register patched in at code generation
time. These are the analogues to FPU_R / FPU_W.
MMX_RegRd MMX_RegWr
-- These have no analogues in FPU land. They hold 2 byte insns
which move data to/from a normal integer register (%eax etc),
and so this has to be made explicit so that (1) a suitable
int reg can be patched in at codegen time, and (2) so that
memcheck can do suitable magic with the V bits going into/
out of the MMX regs.
Nulgrind (ok, this is a nop, but still ...) and AddrCheck's
instrumenters have been extended to cover these new UInstrs. All
others (cachesim, memcheck, lackey, helgrind, did I forget any)
abort when they see any of them. This may be overkill but at least
it ensures we don't forget to implement it in those skins.
[A bad thing would be that some skin silently passes along
MMX uinstrs because of a default: case, when it should actually
do something with them.]
If this works out well, I propose to backport this to 2_0_BRANCH.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1483
VG_(handle_esp_assignment)() was needed by a skin (and thus whether to register
it in the baseBlock) was different to that used when determining whether to
call it in code generation... so it could be (attempted to be) called having
not been registered.
Fixed this by consistifying the conditions, using a function
VG_(need_to_handle_esp_assignment)() that is used in both places. The bug
hadn't been found previously because no existing skin exercised the mismatched
conditions in conflicting ways.
Also took VG_(track).post_mem_write out of consideration because it's no longer
important (due to a change in how stack switching is detected).
----
Improved the error message for when a helper can't be found in the baseBlock --
now looks up the debug info to tell you the name of the not-found function.
----
Increased the number of noncompact helpers allowed from 8 to 24
----
Removed a magic number that was hardcoded all over the place, introducing
VG_MAX_REGS_USED for the size of the arrays needed by VG_(get_reg_usage)()
----
Also added these functions
VG_(get_archreg)()
VG_(get_thread_archreg)()
VG_(get_thread_shadow_archreg)()
VG_(set_thread_shadow_archreg)()
which can be useful for skins.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1419
- Factored out a lot of commonality between AddrCheck and MemCheck. Basic
idea is that common code goes into a single file in MemCheck, and AddrCheck
peeks in and "borrows" it.
More or less, only identical code or identical-with-respect-to-subtypes
code was factored out.
Identical-with-respect-to-subtypes means that some enum types (SuppKind,
ErrorKind, etc) were merged because they were identical except that
MemCheck had some extra constants. So some of the code borrowed by
AddrCheck contains cases it never needs. But that's not so bad, avoiding
the duplication is IMHO more important.
Removed:
- ac_include.h, it wasn't necessary
- All the old debugging stuff from ac_main.c (printing shadow regs, not
applicable for AddrCheck).
- MANUAL_DEPS from memcheck/Makefile.am because it wasn't doing anything
- Some unnecessary crud from addrcheck/Makefile.am
Added:
- memcheck/mc_common.{c,h}
- memcheck/mc_constants.h
- addrcheck/ac_common.c, which simply #includes memcheck/mc_common.c. This
hack was required because there is no way (that I could work out) to tell
Automake that it should build ../memcheck/mc_common.o before building
AddrCheck.
Changed:
- a lot of prefixes from SK_ to MC_; only core/skin interface functions are
prefixed with SK_ now. This makes it clear which functions are from the
core/skin interface, and for AddrCheck it's clear which functions are
shared with/borrowed from MemCheck. Changed some related prefixes for
consistency.
- Also factored out some duplication within AddrCheck -- some accessibility
checking was needlessly split up into separate read and write checks that
did the same thing.
Unchanged:
- I considered moving the leak detector out of core into mc_common.c, but
didn't, because it constantly accesses ShadowChunk fields and converting to
get/set methods would have been a total pain.
- Left old debugging stuff in for MemCheck, although I seriously doubt it
would still work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1325
that changes will cause binary incompatibilities. Mostly done by hiding naked
structs with function calls.
Structs hidden in this way were: UCodeBlock, SkinSupp and SkinError (which were
merged back with CoreSupp and CoreError into single types Supp and Error),
ShadowChunk, VgDetails, VgNeeds and VgTrackEvents. The last three are the most
important ones, as they are (I think) the most likely to change.
Suitable get()/set() methods were defined for each one. The way UCodeBlocks
are copied for instrumentation by skins is a little different now, using
setup_UCodeBlock. Had to add a few other functions here n there. Changed
how SK_(complete_shadow_chunk) works a bit.
Added a file coregrind/vg_needs.c which contains all the get/set functions.
It's pretty simple.
The changes are not totally ideal -- eg. ShadowChunks has get()/set() methods
for its `next' field which arguably shouldn't be exposed (betraying the fact
that it's a linked list), and the get()/set() methods are a bit cumbersome at
times, esp. for `Error' because the fields are accessed quite a few times, and
the treatment of Supps and Errors is a bit inconsistent (but they are used in
different ways), and sizeof_shadow_blocks is still a hack. But still better
than naked structs. And one advantage is that a bit of sanity checking can be
performed by the get()/set() methods, as is done for VG_({get,set}_sc_extra)()
to make sure no reading/writing occurs outside the allowed area.
I didn't do it for UInstr, because its fields are accessed directly in lots and
lots of spots, which would have been a great big pain and I was a little
worried about overhead of calling lots of extra functions, although in practice
translation times are small enough that it probably doesn't matter.
Updated the example skin and the docs, too, hurrah.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1314
39-lock-prefix
Add a new UInstr LOCK to represent a "lock" prefix in the instruction
stream. This has the same semantics as NOP, but allows a skin to tell
whether a group of UInstrs associated with an x86 instruction are
meant to be locked.
HELGRIND: uses the LOCK UInstr to automatically take and release a
special __BUS_HARDWARE_LOCK__ around locked instructions. This only
works properly if all instructions touching a given address are locked
(even reads).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1310
files, into vg_skin.h:
uInstr0, uInstr1, uInstr2, uInstr3, nameIReg, nameISize, nameSReg,
newTemp, newShadow, uLiteral, uCCall
As macros they avoid namespace problems (they expand to VG_(whatever)) so
this should work fine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1182
from core error ones:
- Split up VG_(panic) into VG_(core_panic) and VG_(skin_panic)
- Likewise, split vg_assert into vg_assert and sk_assert
- Added a new need string: `bug_reports_to'
- Removed VG_(skin_error) which was a previous wussy attempt at this change.
This removed the need for the hacky redeclaration of VG_(skin_error) in
vg_profile.c, which is good.
At the moment, Julian and Nick's email addresses are hard-coded into each skin
individually, rather than using a #define in vg_skin.h, because that didn't
feel quite right to me... jseward@acm.org is still done with a #define for
core errors, though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1164
use_under_scores instead, to be consistent.
Also added some missing 'extern's on function declarations in vg_skin.h.
Also added a quick note in vg_regtest.in on the simplest way to run regression
tests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1135
- changed lots of Makefile.am files
- changed configure.in
- changed lots of #include lines for changed file names
- changed lots of file headers n footers for changed file names
- changed vg_regtest to handle new directory structure -- recursively
traverses subdirectories for .vgtest test files
- changed lots of paths in memcheck/ regression test expected outputs
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1090
