compiler symbols rather than our own symbols for the architectures (we
already were, more or less). This simplifies the build, hurrah!
I also inverted the sense of the NVALGRIND ifdefs, to make them easier to
read, and fixed up some comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3739
- All the subdirectories have gone: arm/, x86/, amd64/, linux/,
x86-linux/, amd64-linux/, arm-linux/.
- The following files were moved out of those directories into include/:
amd64-linux/vki_arch.h --> vki-amd64-linux.h
x86-linux/vki_arch.h --> vki-x86-linux.h
x86-linux/vki_arch_posixtypes.h --> vki_posixtypes-x86-linux.h
linux/vki.h --> vki-linux.h
amd64-linux/vki_arch_posixtypes.h --> vki_posixtypes-amd64-linux.h
- The following very small files were inlined into tool.h using the "#if
defined(VGP_x86)..." technique:
x86/tool_arch.h
arm/tool_arch.h
amd64/tool_arch.h
The same technique was used twice to include the appropriate
vki-$PLATFORM and vki-$OS files into tool.h.
- The other files in those directories were removed.
- The build is much simpler, since we have 7(!) fewer Makefile.am files.
Far fewer -I options are needed when compiling, too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3733
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
with SegInfo.symtab.
Also renamed VG_(symtab_{inc,dec}ref)() as VG_(seginfo_{inc,dec}ref)()
for the same reason.
Also renamed various SegInfo variables from "seg" to "si" to avoid
confusion with the many Segment variables called "seg".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3709
layer above the printf stuff in vg_mylibc.c, which is layered over
m_debuglog. This makes the module interfaces neater, more consistent, and
cuts 40 lines of code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3670
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
required moving a lot of stuff around. I deleted
VG_(set_return_from_syscall_shadow)() and VG_(get_exit_status_shadow)(),
which screwed up the modularity and weren't being used and can be
simulated in other ways with a bit of care.
What are the chances that I've added and moved all the files correctly
in this commit, and not broken the amd64 port?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3636
ifdeffery in a sane way where it's absolutely unavoidable. When
building the core, eg on amd64-linux, the following preprocessor
symbols are defined:
VGA_amd64
VGO_linux
VGP_amd64_linux
etc on other platforms.
Also, include/basic_types.h now defines VG_WORDSIZE and this is what
should be used for ifdefs that need to know the host word size.
ifdefs based on the C compilers built-ins such as __amd64__ etc
are deprecated and will be done away with.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3590
same logging mechanism to emit both end-user messages and debugging-
valgrind-itself messages. This commit creates a new mechanism for the
latter purpose.
The main feature of m_debuglog is that it has zero dependencies on any
other module and therefore can safely operate all the way through
stage1 and stage2 startup. It is restricted to emitting debug info on
file descriptor 2 (stderr), but that's not a big deal.
As a result of this change the basic formatted-print routines
(vprintf) have been moved from vg_mylibc.c into m_debuglog, so that
m_debuglog remains standalone.
The %y format string is currently disabled, since supporting it ("show
symbol corresponding to this address") would create a dependency from
m_debuglog to the entire debug-info reading machinery and all the
stuff that depends on, thereby making a nonsense of m_debuglog being
standalone. Its omission does not seem to cause any regression tests
to fail, though.
The debug logger is activated with "-d". More "-d"s make it more
verbose.
m_debuglog.o is linked into both stage1 and stage2, but as it is
completely standalone this causes no particular problems.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3559
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
core.h and tool.h into pub_core_errormgr.h and pub_tool_errormgr.h. All
just to improve general modularity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3532
string explaining more detail if the assertion fails (eg. the value of the
bogus variable) using printf-style format arguments.
One consequence of this is that you can do something like
vg_assert2(0, "bad bad bad");
instead of calling VG_(core_panic). The advantage of the new approach is
that it shows the file/function/line info for the failing code, whereas
VG_(core_panic)() does not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3528
controlled (rounding user malloc requests up to a multiple of 4).
Subsequent changes to memcheck made it more or less pointless, it is a
time waster in the malloc/free path, and nobody ever used it AFAIK.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3522
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
valgrind-listener.c, don't use the VG_ prefix on its equivalent, because
it's a local definition.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3454
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
look like that much, but it's a good first step; there's more to come.
- vg_errcontext.c:gen_suppressions() and vg_symtab2.c:VG_(mini_stack_dump)()
had very similar stack-trace-traversing loops. I factored these out into
the higher-order function VG_(apply_ExeContext)(). I put this into
vg_execontext.c, which is the obvious spot. This is good because before
this change we had two functions, neither in vg_execontext.c, which were
crawling all over ExeContexts -- they shouldn't have to do that.
- Removed VG_(mini_stack_dump)(), which was almost identical to
VG_(pp_ExeContext)().
- Removed dead function VG_(get_EIP_from_ExeContext)().
- Replaced a call to VG_(get_ExeContext2)() with the simpler
VG_(get_ExeContext)() in vg_scheduler.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3394
