Monitor command useful for debugging/investigation of Valgrind unwinder and/or
gdbserver/gdb stack trace.
The Valgrind unwinder has some limitations compared to the GDB unwinder.
(see e.g. 278972).
With this monitor command, it is easy to see if the Valgrind unwinder
produces something different than the GDB unwinder.
Fixes#279212. (Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12203
print the object and SVMA too, so as to make it easy to find the
relevant bit of code by objdump -d of the object, even if the
function name is unknown. Also re-order some of the fields.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12184
and use read_Type routines instead as they work rather better on strict
aligned (or semi-strict a la ARM) machines. Fixes#282527.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12083
Those are obtained by looking at some commonly defined environment
variables.
That should help with problems where /tmp is shared or process IDs get
recycled. We had some intermittent nightly build issues because of that.
Partial fix for bugzilla #280757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12071
VG_MINIMAL_SETJMP and VG_MINIMAL_LONGJMP introduced in r12067.
With this commit, it should be possible to build a working 64 bit
Valgrind using the default gcc as supplied with Xcode 4.1 on OSX 10.7.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12070
VG_MINIMAL_LONGJMP directly, rather than using __builtin_setjmp
and __builtin_longjmp, since clang-2.9 miscompiles the latter
(by completely ignoring it.)
Also, add comment about the return type for VG_MINIMAL_SETJMP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12067
and TMPDIR which was introduced when fixing bugzilla #267020.
Factor out VG_(tmpdir). New function VG_(vgdb_path_prefix).
Partially fixes bugzilla #280757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12063
confusing control flow, by separating the logic for "is there a
debuginfo file to be found?" from that of "if a debuginfo file was
found, let's record certain facts (section offsets etc) about it."
This makes it possible to add arbitrary other schemes for finding
debuginfo files without further complicating the existing control flow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12056
10% reduction in debuginfo storage requirements for large applications
on 32 bit platforms. This code had been present since the MacOSX port
was merged but had been disabled. Remove equivalent code for
shrinking the symbol tables since they are much (4 x) smaller than the
line number tables, trimming them is hardly worth the effort.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12050
bits of assembly which finally cause the thread to exit. How this
ever worked before, on any platform, beats me. The lack was causing
some Android builds to segfault at thread exit. Only the s390 version
was correct.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12049
splittable superblocks. Bug #282105.
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
A previous patch (bug 250101) introduced the concept of reclaimable
superblock: a superblock that cannot be splitted in smaller blocks
and that can be munmapped.
This patch generalises the reclaimable concept : all superblocks are
now reclaimable. To reduce fragmentation, big superblocks are still
kept unsplittable.
The patch has 4 aspects:
1 The previous concept of 'reclaimable superblock' is renamed
'unsplittable superblock' (this is a mechanical change).
2 Ensure that splittable blocks can be reclaimed :
After each free, if the free results in a merged block which
completely covers the superblock, then the superblock can be reclaimed.
3 If a superblock is reclaimed and there exists some translations
for this superblock then discard the translations.
Note : I did not understand the comment speaking about
circular dependency. Just calling VG_(discard_translations) seems
to cause no problem. As m_transtab.c does not allocate client memory,
I believe no circular (dynamic) dependency can be done.
4 Activate 'unsplittable superblock' for all arenas.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12047
in common.
To accomplish that without penalizing the non-profiling dispatcher
we do the stats gathering *after* the jitted code returns to the
dispatcher. For that to work properly, we need to stash away the
instruction adddress before entering the jitted code so we can use
it later. (See also VEX r2208).
Two other tweaks are included here:
(1) For the non-profiling dispatcher it is not necessary to update
the LR in each iteration. Quite obviously the jitted code cannot
modify the LR in its iteration because it needs it at the very end
when it returns. So we move this step out of the core loop.
(2) Move loading the address of VG_(tt_fast) past testing for a changed
guest state pointer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12044
* configure.in support
* new supp file darwin11.supp
* comment out many intercepts in mc_replace_strmem.c and
vg_replace_malloc.c that are apparently unnecessary for Darwin
* add minimal handling for the following new syscalls and mach traps:
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
* wqthread_hijack on amd64-darwin: deal with
tst->os_state.pthread having an apparently different offset,
which caused an assertion failure
* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
cleanup added in r12041/12042 to handle apparently new dyld
behaviour, which is to map text areas r-- first and only
vm_protect them later to r-x.
The following cleanups remain to be done
* remove apparently pointless, commented out wrapper macro
invokations in mc_replace_strmem.c, eg
//MEMMOVE(VG_Z_DYLD, memmove)
(or determine that they are still necessary, and uncomment)
* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
there
* write proper syscall wrappers for
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
These are currently just no-ops and may be causing Memcheck to
report false undef-value errors
* figure out why it doesn't work properly unless built with gcc-4.2 on
Lion.
gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1). Plain
gcc is the hybrid gcc-front-end clang-back-end thing
(i686-apple-darwin11-llvm-gcc-4.2). Whereas on Snow Leopard, plain
gcc is the normal gcc.
The symptoms of the failure are that wqthread_hijack in
syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
at the end (you need a pretty complex threaded app to trigger this),
which makes me think that either ML_(wqthread_continue_NORETURN) or
call_on_new_stack_0_1 do return, which they are not expected to.
* figure out if some of the uninitialised value errors reported in
system libraries on are caused by Memcheck being confused by LLVM
generated code, as per bug #242137
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043
