If valgrind is started with --vgdb-prefix arg, then callgrind_control
cannot find and control this valgrind.
So, add an (optional) argument to callgrind_control,
and have callgrind tool report the needed vgdb prefix argument
if the user supplied this arg.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13769
expected to be loaded (as expressed in the ELF headers) and where it was
actually loaded, and not (as valgrind was doing) the absolute value of the
load address for the interpreter.
Note that when prelink is not in use the two are normally the same, as the
intpreter (like all shared libraries) is normally linked with a zero load
address. When prelinked that is no longer true.
With that fixed, the hack to patch out AT_BASE to avoid confusing gdb on
systems where prelink is in use is no longer needed.
Fixes BZ#329612
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13768
When all threads are blocked in a syscall, DRD_(thread_get_running_tid)()
returns (or can return?) a "valid" DrdThreadId (probably the last one
that was running ?).
However, in such a situation, VG_(get_running_tid)() returns 0 (as effectively
there is no thread running).
This discrepancy (drd_tid "valid" and "vg_tid" invalid) can (probably) only
happen with gdb monitor commands, as a thread can (normally) execute a
client request only when it is running.
However, vgdb can "force" the invocation of the gdb monitor client request,
even if no thread is running.
In such a case, the assert should not verify that drd_tid and vg_tid are
consistent.
To reproduce the problem:
./vg-in-place --tool=drd sleep 60
and in another window:
./coregrind/vgdb help
which then gives
...
drd: drd_clientreq.c:84 (handle_client_request): Assertion 'DRD_(VgThreadIdToDrdThreadId)(vg_tid) == drd_tid' failed.
==4208== at 0x3801DE1D: report_and_quit (m_libcassert.c:260)
==4208== by 0x3801E034: vgPlain_assert_fail (m_libcassert.c:340)
==4208== by 0x380026CC: handle_client_request (drd_clientreq.c:84)
==4208== by 0x3806EE8F: handle_gdb_monitor_command (server.c:490)
==4208== by 0x3806F07A: handle_query (server.c:580)
==4208== by 0x3806FDB2: server_main (server.c:915)
==4208== by 0x3806B01C: call_gdbserver (m_gdbserver.c:706)
==4208== by 0x3806B8F2: vgPlain_invoke_gdbserver (m_gdbserver.c:892)
...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13765
Use ULong rather than UInt for coredump file size.
Tested manually by
ulimit -c 4294967296
./vg-in-place ./gdbserver_tests/gone abort
valgrind creates vgcore.xxxxx unusable by GDB.
With the fix, GDB can read the core dump.
Patch from Romain Geissler
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13762
After the thread is detached not all thread memory is freed. This memory (dtv-dynamic thread vector)
can be used by the main thread. There are two types of run-time handling of TLS.
Difference is in the position of memory. It can be either before the thread pointer or
after the thread pointer.
Taken form the document http://www.akkadia.org/drepper/tls.pdf:
"Variant I for the thread-local storage data structures were developed
as part of the IA-64 ABI. Being brand-new, compatibility was no issue. The thread
register for thread t is denoted by tpt. It points to a Thread Control Block (TCB) which
contains at offset zero a pointer to the dynamic thread vector dtvt for the thread.
Variant II has a similar structure. The only difference is that the thread pointer
points to a Thread Control Block of unspecified size and content. Somewhere the TCB
contains a pointer to the dynamic thread vector but it is not specified where. This is
under control of the run-time environment and the pointer must not be assumed to be
directly accessible; compilers are not allowed to emit code which directly access the
dtvt."
Because of this we have two types of error when the program ends:
possibly lost, and definitely lost.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13761
* addition of VG_(needs_print_stats) in pub_tool_tooliface.h
* use the above in memcheck and helgrind
* output valgrind stats and calls print_stats in server.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13760
Iop_GetMSBs8x16, since the presence of those usually implies PMOVMSKB
instructions in the block, which can mean "inlined string operations".
Reduces the noise level a lot in some icc12 -O2 generated sequences.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13757
On MIPS architecture helgrind is showing race condition error in printf if
the printf is first time called from the child thread. If we call printf
from the main for the first time we will suppress this error on mips.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13749
to make copy/paste and then editing the command easier,
put the --pid=3393 at the end of the instruction output by valgrind.
So, in gdb command history, one can just recuperate the previous target
command in the history and more easily change the pid.
I.e. have:
target remote | /home/philippe/valgrind/refactor_vgdb/Inst/lib/valgrind/../../bin/vgdb --vgdb-prefix=truc --pid=3393
instead of
target remote | /home/philippe/valgrind/refactor_vgdb/Inst/lib/valgrind/../../bin/vgdb --pid=3393 --vgdb-prefix=truc
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13747
Fix some typo error and some errors in tests that was discovered while running Valgrind on MIPS/Android.
In some cases initial FCSR value wasn't being set properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13746
Use a pool allocator for the MallocMeta struct that helgrind maintains
for each client allocated block.
For perf/heap on x86, this decreases the max amount of mmap-ed memory
for the core area from 56Mb to 36Mb.
On amd64, decreases from 104Mb to 62Mb.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13744
vgdb.c contained (conditionally compiled) "invoker" code to have ptrace syscalls
used to allow gdb/vgdb to connect to a valgrind process blocked in a syscall.
This "invoker" code is ptrace based.
Not all platforms are using ptrace.
=> refactor vgdb so as allow invoker code to be added more cleanly
for non ptrace based platforms (e.g. Darwin, Solaris).
* add file vgdb.h for:
- definition of the vgdb-invoker interface
- common declarations between vgdb.c and vgdb-invoker implementations
* move ptrace related code from vgdb.c to new file vgdb-invoker-ptrace.c
* new file vgdb-invoker-none.c containing an empty invoker implementation
used on platforms that do not (yet) have a invoker implementation
(e.g. android and darwin).
* modified Makefile.am to use one of the vgdb-invoker-*.c file depending
on the platform.
* small changes related to changing ptraceinvoker to invoker in various files:
gdbserver_tests/make_local_links, gdbserver_tests/nlcontrolc.vgtest,
gdbserver_tests/mcinvokeRU.vgtest, gdbserver_tests/nlsigvgdb.vgtest
gdbserver_tests/mcinvokeWS.vgtest, coregrind/m_gdbserver/README_DEVELOPERS
Patch from Ivo Raisr, slightly modified
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13743
fixed in r13709 326983 Clear direction flag after tests on amd64.
fixed in r13712 327238 Callgrind Assertion 'passed <= last_bb->cjmp_count' failed
fixed in r13715 327837 dwz compressed alternate .debug_info and .debug_str not read correctly
fixed in r13718 327916 DW_TAG_typedef may have no name
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13740
* add the new sections for next 3.10.0 release in NEWS.
* add file README_DEVELOPERS_processes.
As discussed on valdev and documented in README_DEVELOPERS_processes,
the idea is to document fixed bugs or new features in NEWS together
with the commit fixing/implementing these.
Looking at SVN, the below bugs should be added in 3.10.0 fixed bugs.
I will add them in NEWS shortly.
Thanks
Philippe
r13709 | tom | 2013-11-01 11:46:28 +0100 (Fri, 01 Nov 2013) | 2 lines
Clear direction flag after tests on amd64. BZ#326983.
r13712 | weidendo | 2013-11-12 16:32:58 +0100 (Tue, 12 Nov 2013) | 17 lines
Fix bug 327238.
assertion failure in Callgrind: bbcc.c:585 (vgCallgrind_setup_bbcc):
Assertion 'passed <= last_bb->cjmp_count' failed
r13715 | mjw | 2013-11-20 12:54:38 +0100 (Wed, 20 Nov 2013) | 5 lines
dwz compressed alternate .debug_info and .debug_str not read correctly.
Bug #327837. The buildid from the .gnu_debugaltlink section was parsed
incorrectly (from the wrong offset). Causing the debug alt file not to
be found.
r13718 | mjw | 2013-11-24 18:19:35 +0100 (Sun, 24 Nov 2013) | 5 lines
Bug 327916 - DW_TAG_typedef may have no name
We already accepted DW_TAG_typedef without a name for Ada. But g++ for
OpenMP can also emit such nameless DW_TAG_typedefs. Just accept them.
Also fix up anonymous enum and typedef printing in tytypes.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13739
This is new in Xen 4.4.
From: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13738
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13737
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13736
And some of the sub-subops. It is a little hacky given the legacy way of
having several methods of enabling/disbling LOG_DIRTY mode.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13735
Xen reads 'num' and 'array' from the structure, and reads the entire buffer.
Nothing gets written back.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13734
Xen reads 'num' and the 'array' pointer from ARG1, and proceeds to read and
modify-in-place the entire userspace array.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13733
The semantics of XEN_DOMCTL_gethvmcontext are little interesting.
If the 'buffer' field of the structure is NULL, the hypercall is a request for
the required buffer size, which written into the 'size' paramater.
If 'buffer' is non NULL, Xen will write to the buffer, and update 'size' with
the amount of data written.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13732
Xen reads the entire structure and writes nothing.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13731
Xen reads the entire structure, and if the space is _gmfn, will write the
structure back
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13730
The XENMEM_machphys_mfn_list implementation reads 'max_extents' and
'extents_start'. It writes to the array at 'extents_start', and writes the
number of extents written into the 'nr_extents' field.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13729
Xen reads a 16 bit domid from the pointer provided in ARG2, but does not write
anything back.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13728
Xen does not read or write any memory for this hypercall
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13727
and an implementation of XEN_TMEM_control save_begin.
Xen will read various fields at various time, but write nothing back for a
save_begin subop.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13726
From: Andrew Cooper <andrew.cooper3@citrix.com>
Also add a default case so future bumps of the sysctl interface version dont
result in spurious passes of the IOCTL handler.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13725
r13682 Initial cut at 3.9.0 release notes.
r13683 Remove duplicate NEWS entries for 3.9.0.
r13689 Minor docs/NEWS fixes
r13690 Documentation updates for 3.9.0.
r13691 More documentation updates, re leak-checker changes
r13692 NEWS: Note increased max mem size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13724
