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
carry an Int. This is confusing but works on 32-bit platforms; on
64-bit ones, gcc complains about the cast. This commit adds another
kludge to keep gcc quiet. Really this should be fixed properly. The
casting-abuse is 'undone' in case LeakErr in MAC_(pp_Shared_Error).
This should really be fixed properly. If this .string isn't always
a string, perhaps it should be renamed 'auxword' and turned into a
UWord which is guaranteed castable to/from pointer on any platform.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3676
into a new module m_tooliface. Pretty straightforward. Touches a lot
of files because many files use this interface and so need to include
the headers for the new module.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3652
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
in response to a mixed-units (bytes and words) error we had involving
VGA_STACK_REDZONE_SIZE (which is now VGA_STACK_REDZONE_SZB).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3639
to check that the threading library hadn't messed up errno. Now that
doesn't make much sense any more. Anyway, now it annoyingly fails due
to memcheck reporting bugs in libpthread et al. Move it to corecheck
so at least it can continue to run and hopefully not continually fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3611
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
vex rev 1144.
* Observe that mkLazy2 generates IR which often turns into
long and slow code sequences in the back end, primarily because
PCast operations are expensive. Add a couple of special
cases which give noticably better performance when handling
FP-intensive code on x86.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3572
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
account for the fact that on amd64 (really, on amd64-linux) the area
up to 128 bytes below the stack pointer is accessible. This meant
moving the definitions of VGA_STACK_REDZONE_SIZE to tool-visible
places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3546
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
