relies on --smc-support=all to work correctly. Hence it tests the
s-m-c support at least on x86. Jump through various hoops to defeat
vex's basic-block-chasing optimisation, which has an annoying habit of
making this test work correctly even without --smc-support=all.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4123
bit-rotted badly and was clogging up the code.
I put the useful remnants in docs/porting-to-ARM in case anyone ever
wants to try porting to ARM again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4092
get included in the distro now, not just the ones for the arch/platform
that the distro tarball is built on.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4085
no real point in having them in corecheck/tests since they're not testing
anything that Nulgrind doesn't provide.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4048
Plenty still to do, but simple programs like ls seem to run ok
Thanks, Paul, for having your ppc port of valgrind 2.4 to work from!
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3969
- 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
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
attempt to flush out any register-number bugs that might be lurking.
It would be nice to be able to do the same with the integer registers,
but gcc-3.3.4 is too stupid to understand asms with clobbered
registers "r8d", etc (plain "r8" etc is OK) and I am too ignorant of
perl to know how to mash r8b/r8w/r8d back into plain "r8" etc for the
clobbered registers list.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3659
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
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
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
