* 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
contains a bunch of fields which are used as a very simple state
machine that observes mmap calls and decides when to read debuginfo
for the associated file. This change moves these fields into their
own structure, struct _DebugInfoFSM, for cleanness, so as to make it
clear they have a common purpose.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12041
The testcase used to cause a SIGILL because the address of the bogus
mutex 1 + (char*)&mx[0] denotes a memory location that will eventually
appear in a compare-and-swap instruction. That insn does not allow
memory operands that are not word-aligned. Hence, the SIGILL.
With this fix both incarnations of this testcase (in helgrind and drd)
pass.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12038
an invalid siginfo for SIGBUS. Hunted down and fixed by
Christian Borntraeger (borntraeger@de.ibm.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12032
machines we need to sleep longer. See bugzilla #268623 comment #2.
So let's sleep 500ms instead of 100ms, get rid of the load
barrier and enable the testcase for s390x again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12031
This is due to older versions of GCC who use the MVC insn for
assignments and that creates a sequence of 1-byte memory accesses.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12026
macro, set di->soname back to NULL, so that if we later reenter with
the same 'di', we don't fall over the initial di->soname == NULL
assertion.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12023
The vgdb "status" monitor command is still available, but
used for pretty printing of status information now (acutally,
just some place holder for real information up to now: just
number of running threads). The internal interface used by
callgrind_control to provide stack traces and event counts
is using "status internal", and is not documented, as the
format is not for human consumption.
This also adds some documentation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12014
Patch by Philippe Waroquiers, slightly changed.
This actually was a regression from 3.6.1, but the patch
also improves on printed messages, and refactors common
code between cachegrind and callgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12013
* move MEMCPY(NONE, ZuintelZufastZumemcpy) to the correct ifdef;
it got put in the wrong place by r12009 a couple of hours ago.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12010
the Linux and Darwin definitions so they are in completely separate
ifdefs -- iow, remove any definitions that are common to both. This
gives some duplication, but the upside is that it is now possible to
edit the Darwin intercepts without fear of breaking the Linux ones.
This will be important when it comes to supporting OSX 10.7.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12009
Note: I haven't analyzed yet since which commit these false positives
started to appear but it's most likely a commit applied after the 3.6
release.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12003
we are cleaning up the environment before an exec, otherwise we
will seg fault if the string is read only. Fixes#270326.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12001
where it otherwise wouldn be. On x86-linux running Memcheck, gives a
6% instruction count reduction and a 10% reduction in memory traffic.
(Duh!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11998
