noaccess, writable, readable, other
Now they are:
noaccess, undefined, defined, partdefined
As a result, the following names:
make_writable, make_readable,
check_writable, check_readable, check_defined
have become:
make_mem_undefined, make_mem_defined,
check_mem_is_addressable, check_mem_is_defined, check_value_is_defined
(and likewise for the upper-case versions for client request macros).
The old MAKE_* and CHECK_* macros still work for backwards compatibility.
This is much better, because the old names were subtly misleading. For
example:
- "readable" really meant "readable and writable".
- "writable" really meant "writable and maybe readable, depending on how
the read value is used".
- "check_writable" really meant "check writable or readable"
The new names avoid these problems.
The recently-added macro which was called MAKE_DEFINED is now
MAKE_MEM_DEFINED_IF_ADDRESSABLE.
I also corrected the spelling of "addressable" in numerous places in
memcheck.h.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5802
Memcheck, replacing the 9-bits-per-byte shadow memory representation to a
2-bits-per-byte representation (with possibly a little more on the side) by
taking advantage of the fact that extremely few memory bytes are partially
defined.
For the SPEC2k benchmarks with "test" inputs, this speeds up Memcheck by a
(geometric mean) factor of 1.20, and reduces the size of shadow memory by a
(geometric mean) factor of 4.26.
At the same time, Addrcheck is removed. It hadn't worked for quite some
time, and with these improvements in Memcheck its raisons-d'etre have
shrivelled so much that it's not worth the effort to keep around. Hooray!
Nb: this code hasn't been tested on PPC. If things go wrong, look first in
the fast stack-handling functions (eg. mc_new_mem_stack_160,
MC_(helperc_MAKE_STACK_UNINIT)).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5791
For each byte in the range, if the byte is addressible, make it be
initialised, but if it isn't addressible, leave it alone. So it's
like a version of make_readable which doesn't alter addressibility.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5736
- when recording the non-redirected address in guest_NRADDR, also
snapshot the current R2 value, as that will be needed to run the
original safely
- As a consequence, the original-function information extracted by
VALGRIND_GET_ORIG_FN is different on ppc64-linux (2 words) from
all other platforms (1 word). So change the type of it from
void* to a new type OrigFn which can be defined differently for
each platform.
- Change the CALL_FN_* macros for ppc64-linux to save/restore
R2 values appropriately.
- ppc64-linux: detect overflow/underflow of the redirect stack
and bring Valgrind to a halt if this happens
- Update VG_CLREQ_SZB for ppc32/64 (was out of date).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5569
- fixed launcher.c to recognise ppc32/64-linux platforms properly
- lots of assembly fixes to handle func descriptors, toc references, 64bit regs.
- fixed var types in vki-ppc64-linux
Now gets as far as VG_(translate), but dies from a case of invalid orig_addr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5299
negatives, but only in the following unlikely circumstances: for an
8-byte store, which is handled by by the slow path (due to
misalignment or incomplete addressibility). In this case, the bug
caused the top 32 of the written V bits to be forced to zero
("defined"). This would not have affected the vast majority of 8-byte
stores since almost all of them would either have been handled by the
fast case or would have the top 32 V bits as zero anyway (almost
certainly both).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5222
- on 64-bit platforms, double the size of the supported address
space to 32G.
- Increase the size of the ExeContext table 6 times. Some very
large apps have been observed to have been doing a lot of
searching in the old 4999 entry table. This table may be
OSetified in the fullness of time.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4808
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
higher-order functions for traversing data structures. The higher-order
approach is too clumsy due to the lack of polymorphism and closures; you
have to use void* too much and it is more verbose than it should be.
Hence, I replaced all the uses of HT_first_match() and
HT_apply_to_all_nodes() with equivalent uses of the hashtable iterator.
Also replaced higher-order traversal functions for Memcheck's freed-list
and the thread stacks with iterators. That last change changes the
core/tool interface, so I've increased the version number.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4415
- Added some useful hash table functions (vanilla lookup() and remove()).
[Actually, I accidentally added them with my previous commit]
Replaced various simple uses of VG_(HT_get_node) with these new functions.
- Passing record_freemismatch_error() the MAC_Chunk of the freed heap block.
So now we don't need to call describe_addr() to re-find that block, which
means that we can remove the MAC_Chunk from the malloc_list earlier, rather
than having to do a lookup and then later remove it with the stupid removal
handle returned by VG_(HT_get_node)().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4379
This involved some serious nastyness from the Department of Cpp Abuse.
Memcheck still bombs on ppc32 for unknown reasons.
There are still endianness issues within these functions, I think.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4129
things. These made sense when the arch/OS/platform-specific code was in
one module, but as that code got mixed in with generic code the boundary
between generic and non-generic blurred, and the distinction made less
sense. So let's get rid of them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4002
I've changed it so it now is, which makes it consistent with the
other 'needs'. Because of this, I was also able to invert the dependence
between m_mallocfree and m_tooliface, which is related to setting
the redzone size for client heap blocks. As a result, m_tooliface
now doesn't depend on anything except pub_core_basics.h, hooray!
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3979
- Broke part of m_scheduler off into a new module m_threadstate. It
contains ThreadState, VG_(threads)[] and some basic operations on the
thread table. All simple stuff, the complex stuff stays in m_scheduler.
This avoids lots of circular dependencies between m_scheduler and other
modules.
- Managed to finally remove core.h and tool.h, double hurrah!
- Introduced pub_tool_basics.h and pub_core_basics.h, one of which is
include by every single C file.
- Lots of little cleanups and changes related to the above.
- I even did a small amount of documentation updating.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3944
enough to cover 1.25GB of auxiliary address space. This is all still
a hack until such time as the address space manager is rewritten, but
should make things work more reliably on amd64-linux for now.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3859
As part of this, killed the VG_STRINGIFY macro, which was used to expand
out names like "VG_(foo)" and "vgPlain_foo" in assertion failure
messages. This is good since we actually want the "VG_(foo)" form used
in these messages.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3842
relying on any other modules -- in m_libcbase.
Also converted the 'size' parameters to functions like VG_(memcpy) and
VG_(strncpy) from Int to SizeT, as they should be.
Also removed VG_(atoll16) and VG_(toupper), which weren't being used.
Also made VG_(atoll36) less flexible -- it now only does base-36 numbers
instead of any base in the range 2..36, since base-36 is the only one we
need. As part of that, I fixed a horrible bug in it which caused it to
return incorrect answers for any number containing the digits 'A'..'I'!
(Eg. for "A; it would return 17 instead of 10!)
Had to disable the assertions in VG_(string_match), since this module can't
see vg_assert, which wasn't ideal but also isn't a disaster.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3838
form. The relevant flag is --xml=yes. Currently this only works with
Memcheck.
Specifying this flag fixes various other options relating to verbosity
and behaviour of the leak checker, so that the resulting output is in
a relatively fixed form suitable for parsing by GUIs.
Still to do:
* Add mechanism to show error counts
* Add regression test
* Document the resulting format
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3773
rather than `foo', as www.cl.cam.ac.uk/~mgk25/ucs/quotes.html explains
we should (in more detail than you'd imagine was possible). I did this
both in output messages and in some comments, for consistency.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3723
slow down call-return intensive amd64 programs too much. Revised
version is approximately 8 times faster than the naive version.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3689
malloc/free implementation, and m_replacemalloc with the stuff for the tools
that replace malloc with their own version. Previously these two areas of
functionality were mixed up somewhat.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3648
through the VG_(tdict) function dictionary, rather than using TL_(foo)
functions.
This facilitated the following changes:
- Removed the "TL_" prefix, which is no longer needed.
- Removed the auto-generated files vg_toolint.[ch], which were no longer
needed, which simplifies the build a great deal. Their (greatly
streamlined) contents went into core.h and vg_needs.h (and will soon
go into a new module defining the core/tool interface).
This also meant that tool.h.base reverted to tool.h (so no more
accidentally editing tool.h and not having the changes go into the
repo, hooray!) And gen_toolint.pl was removed. And toolfuncs.def was
removed.
- Removed VG_(missing_tool_func)(), no longer used.
- Bumped the core/tool interface major version number to 8. And I
killed the minor version number, which was never used. The layout
of the ToolInfo struct is such that this should not cause problems.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3644
