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
mc_main.c. As so often the case, the regtest system saved the day by
being the first to notice this idiocy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3609
platforms, otherwise the address-masking operations to establish
alignment and primary-mappability are wrong on 64-bit platforms.
Also set the size of fast-mapped address space on 64-bit platforms to
16G.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3580
MC_(helperc_LOADV8) compiles down to just 12 instructions for the
fast-path, which is pretty darn good.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3547
name the events, rather than just number them, which makes it a
lot easier to use
* Based on that, fill in some fast-path cases
{LOAD,STORE}V{4,2,1}. The assembly code looks about the same
length as it did before, on x86. Fast-path cases for the
stack have yet to be done.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3538
there is a better way to handle the 'pessimising cast' family of
operations in such a way that Vex's back-end instruction selectors can
generate better code than they do now, with less verbosity and general
confusingness in the insn selectors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3536
32- and 64-bit targets, little- and big-endian. It does more or less
work on x86 as-is, although is unusably slow since I have knocked out
all the fast-path cases and am concentrating on getting the baseline
functionality correct. The fast cases will go back in in due course.
The fundamental idea is to retain the old 2-level indexing for speed,
even on a 64-bit target. Since that's clearly unviable on a 64-bit
target, the primary map handles only first N gigabytes of address
space (probably to be set to 16, 32 or 64G). Addresses above that are
handled slowly using an auxiliary primary map which explicitly lists
(base, &-of-secondary-map) pairs. The goal is to have the
address-space-manager try and put everything below the 16/32/64G
boundary, so we hit the fast cases almost all the time.
Performance of the 32-bit case should be unaffected since the fast map
will always cover at least the lowest 4G of address space.
There are many word-size and endianness cleanups.
Jeremy's distinguished-map space-compression scheme is retained, in
modified form, as it is simple and seems effective at reducing
Memcheck's space use.
Note this is all subject to rapid change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3535
lot to one. This required two basic changes.
1. Tools are responsible for telling the tool about any functions they
provide that the tool may call. This includes basic functions like
TL_(instrument)(), functions that assist core services such as
TL_(pp_Error)(), and malloc-replacement-related functions like
TL_(malloc)().
2. Tools that replace malloc now specify the size of the heap block redzones
through an arg to the VG_(malloc_funcs)() function, rather than with a
variable VG_(vg_malloc_redzone_szB).
One consequence of these changes is that VG_(tool_init_dlsym)() no longer
needs to be generated by gen_toolint.pl.
There are a number of further improvements that could follow on from this one.
- Avoid the confusingly different definitions of the TL_() macro in the
core vs. for tools. Indeed, the functions provided by the tools now don't
need to use the TL_() macro at all, as they can have arbitrary names.
- Remove a lot of the auto-generated stuff in vg_toolint.c and vg_toolint.h
(indeed, it might be possible to not auto-generate these at all, which
would be nice).
- The handling of VgToolInterface is currently split across vg_needs.c and
vg_toolint.c, which isn't nice.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3487
two halves: stacktrace.c, which deals with getting, traversing and printing
stack traces; and execontext.c, which deals with storing stack traces
permanently in a way that avoids duplicates, and comparing them.
One nice outcome: previously we were often creating ExeContexts, which live
forever, even when they were only needed temporarily. Ie. this was a memory
leak, which has been removed.
As part of this, new headers have been created, carved off core.h and
tool.h. Lots of function names have changed, too.
In Massif, I also changed a lot of "eip" names to "ip" to make them less
x86-specific.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3429
user-specified block stuff, which confused me because I wasn't sure whether
to use the code already in SVN, or the code in CVS. Perhaps that code
doesn't need to be changed.
Unfortunately, Memcheck doesn't work entirely correctly -- I get some
spurious errors. Nonetheless I'm checking it in as a starting point.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3353
because the added VG_(find_root_memory)() is just a stub. And there's a
problem with overlap checking that I haven't worked out yet. Still it's a
start. The commit also brings Memcheck back into the build process,
although mc_main.c is entirely commented out at the moment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3352
