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
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
counterpart VG_(client_alloc) to VG_(get_memory_from_mmap_for_client).
Man, this low level memory management is an undisciplined mess.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3376
to vg_malloc2.c -- the core and tools never do allocations with alignments
different to the default alignment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3343
Also rename the variables involve to lessen the chance of such confusion
occurring again.
MERGED FROM CVS HEAD
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3274
overhaul of the thread support. Many things are now probably broken,
but at least with --tool=none, simple and not-so-simple threaded and
non-thread programs work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3265
string in valgrind.pc.in, so that they describe Valgrind as a "dynamic
binary instrumentation framework", and don't mention platforms at all.
I had to tweak the regtest filters a bit for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3178
It compiles, but aborts immediately if you try to run it.
I didn't include ldt.c; I'm not sure how the LDT is used on AMD64. It can be
added later if necessary.
While doing this, did some 64-bit cleanness fixes:
- Added necessary intermediate casts to ULong to avoid warnings when converting
ThreadId to void* and vice versa, in vg_scheduler.c.
- Fixed VALGRIND_NON_SIMD_CALL[0123] to use 'long' as the return type.
- Fixed VALGRIND_PRINTF{,BACKTRACE} to use unsigned longs instead of unsigned
ints, as needed.
- Converted some offsets in vg_symtab2.h from "Int" to "OffT".
- Made strlen, strncat, etc, use SizeT instead of 'unsigned int' for the length
parameter.
- Couple of other minor things.
I had to insert some "#ifdef __amd64__" and "#ifndef __amd64__" guards in
places. In particular, in vg_mylibc.c, some of our syscall wrappers aren't
appropriate for AMD64 because the syscall numbering is a bit different in
places. This difference will have to be abstracted out somehow.
Also rewrote the sys_fcntl and sys_fcntl64 wrappers, as required for AMD64.
Also moved the ipc wrapper into x86, since it's not applicable for
AMD64. However, it is applicable (I think) for ARM, so it would be nice
to work out a way to share syscall wrappers between some, but not all,
archs. Hmm. Also now using the real IPC constants rather than magic
numbers in the wrapper.
Other non-AMD64-related fixes:
- ARM: fixed syscall table by accounting for the fact that syscall
numbers don't start at 0, but rather at 0x900000.
- Converted a few places to use ThreadId instead of 'int' or 'Int' for
thread IDs.
- Added both AMD64 and ARM (which I'd forgotten) entries to valgrind.spec.in.
- Tweaked comments in various places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3136
run, though. There are lots of stubs to be filled in. (The asm ones currently
just have "swi" in them, which seems to cause seg faults.)
Also, some of the macros are decided dubious, especially:
ARCH_* are bogus
SYSCALL_RET is bogus
PLATFORM_SET_SYSCALL_RESULT is bogus
not sure about SET_SYSCALL_RETVAL
FIRST_STACK_FRAME et al -- bogus?
VG_MAX_JUMPS ?
And in stage2.lds, the 0x8048000 is almost certainly wrong
This required some tweakings of the core:
- some of the vki_*.h kernel types were fixed up
- had to disable the AM_PROG_CC_C_O macro in configure.in, because automake
(autoconf?) didn't like it...
- some "#ifdef __x86__" guards were introduced, for nasty x86 things I don't
yet know how to factor out (trampoline page muck, sysinfo page muck).
- fixed a minor stupidity in vg_proxylwp.c.
- moved the ptrace wrapper into the x86-linux part
- had to change the intercept mangling scheme, to use 'J' instead of '$' as the
escape char because GCC didn't like '$'. This is all very dubious, and only
works because none of our intercepted symbols contains a 'J'. To be fixed up
ASAP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3120
arch-neutral ones like R_STACK_PTR). Where they were used, we now always talk
about an offset into the Vex guest state, and an offset. As a result,
the shadow register get/set functions had to change. They now also use
an offset and size, and in an arch-neutral way.
Also, I combined the five the post_reg_write* functions into a single one that
takes a 'CorePart' parameter (plus also a ThreadId). Also, I added more
arguments (the CorePart, and the ThreadId) to the post_mem_write event, for
consistency with the pre_mem_* events.
Also, I reduced the number of register names that must be specified by each
arch, by factoring out duplication; and shortened their names for the core (eg.
ARCH_STACK_PTR is now STACK_PTR).
Plus some related minor cleanups in syscall wrappers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3094
state pointer points directly at the ThreadState.arch.vex field, thus
updating it in place and avoiding a lot of code (and time-wasting)
which copies stuff back and forth to baseBlock.
Fix zillions of other places in the system where the current thread id
is needed. It is now passed to all needed places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3090
