You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(9) |
|
2
(12) |
3
(19) |
4
(18) |
5
(22) |
6
(25) |
7
(18) |
8
(24) |
|
9
(16) |
10
(15) |
11
(22) |
12
(7) |
13
(19) |
14
(5) |
15
(8) |
|
16
(7) |
17
(8) |
18
(9) |
19
(7) |
20
(13) |
21
(16) |
22
(7) |
|
23
(10) |
24
(8) |
25
(4) |
26
(4) |
27
(9) |
28
(4) |
29
(5) |
|
30
(8) |
31
(4) |
|
|
|
|
|
|
From: <sv...@va...> - 2007-12-04 21:35:54
|
Author: njn Date: 2007-12-04 21:35:55 +0000 (Tue, 04 Dec 2007) New Revision: 7276 Log: Minor Massif docs clarifications. Modified: trunk/massif/docs/ms-manual.xml Modified: trunk/massif/docs/ms-manual.xml =================================================================== --- trunk/massif/docs/ms-manual.xml 2007-12-04 21:27:18 UTC (rev 7275) +++ trunk/massif/docs/ms-manual.xml 2007-12-04 21:35:55 UTC (rev 7276) @@ -427,9 +427,38 @@ point in the program into a single tree, which gives a complete picture of how and why all heap memory was allocated.</para> -<para>The final part of the output is similar:</para> +<para>Note that the tree entries correspond not to functions, but to +individual code locations. For example, if function <function>A</function> +calls <function>malloc</function>, and function <function>B</function> calls +<function>A</function> twice, once on line 10 and once on line 11, then +the two calls will result in two distinct stack traces in the tree. In +contrast, if <function>B</function> calls <function>A</function> repeatedly +from line 15 (e.g. due to a loop), then each of those calls will be +represented by the same stack trace in the tree.</para> +<para>Note also that tree entry with children in the example satisfies an +invariant: the entry's size is equal to the sum of its children's sizes. +For example, the first entry has size 20,000B, and its children have sizes +10,000B, 8,000B, and 2,000B. In general, this invariant almost always +holds. However, in rare circumstances stack traces can be malformed, in +which case a stack trace can be a sub-trace of another stack trace. This +means that some entries in the tree may not satisfy the invariant -- the +entry's size will be greater than the sum of its children's sizes. Massif +can sometimes detect when this happens; if it does, it issues a +warning:</para> + <screen><![CDATA[ +Warning: Malformed stack trace detected. In Massif's output, + the size of an entry's child entries may not sum up + to the entry's size as they normally do. +]]></screen> + +<para>However, Massif does not detect and warn about every such occurrence. +Fortunately, malformed stack traces are rare in practice.</para> + +<para>Returning now to ms_print's output, the final part is similar:</para> + +<screen><![CDATA[ -------------------------------------------------------------------------------- n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B) -------------------------------------------------------------------------------- |
|
From: <sv...@va...> - 2007-12-04 21:27:17
|
Author: sewardj
Date: 2007-12-04 21:27:18 +0000 (Tue, 04 Dec 2007)
New Revision: 7275
Log:
DRD changes (Bart Van Assche)
* Add docs: exp-drd/docs/README.txt
* Added one drd suppression pattern, and cleaned up the suppression file.
* All regression tests now pass on x86_64 and i386, including sigalrm.
* Updated TODO.txt file.
* pth_create_chain test is now started with 100 threads instead of 10
-- 10 was not enough.
* DRD no longer exits on PPC32 and PPC64 but just prints a warning
message before it starts.
Added:
trunk/exp-drd/docs/README.txt
Modified:
trunk/NEWS
trunk/exp-drd/TODO.txt
trunk/exp-drd/docs/Makefile.am
trunk/exp-drd/drd_main.c
trunk/exp-drd/drd_thread.c
trunk/exp-drd/drd_thread.h
trunk/exp-drd/tests/pth_create_chain.vgtest
trunk/glibc-2.X-drd.supp
Modified: trunk/NEWS
===================================================================
--- trunk/NEWS 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/NEWS 2007-12-04 21:27:18 UTC (rev 7275)
@@ -1,7 +1,6 @@
Release 3.3.0 (7 December 2007)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
3.3.0 is a feature release with many significant improvements and the
usual collection of bug fixes. This release supports X86/Linux,
AMD64/Linux, PPC32/Linux and PPC64/Linux. Support for recent distros
@@ -50,7 +49,7 @@
exp-omega/docs/omega_introduction.txt.
* exp-DRD: a data race detector based on the happens-before
- relation. See exp-drd/TODO.txt.
+ relation. See exp-drd/docs/README.txt.
- Scalability improvements for very large programs, particularly those
which have a million or more malloc'd blocks in use at once. These
Modified: trunk/exp-drd/TODO.txt
===================================================================
--- trunk/exp-drd/TODO.txt 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/exp-drd/TODO.txt 2007-12-04 21:27:18 UTC (rev 7275)
@@ -4,13 +4,16 @@
Data-race detection algorithm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Implement glibc version detection in drd_main.c.
+- Rename drd_preloaded.c into drd_intercepts.c.
+- Propose on the Valgrind developers mailing list to add scripts
+ "run-in-place" and "debug-in-place".
- Implement segment merging, such that the number of segments per thread
remains limited even when there is no synchronization between threads.
- Find out why a race is reported on std::string::string(std::string const&)
(stc test case 16).
- Make sure that drd supports more than 256 mutexes.
- Performance testing and tuning.
+- pthread semaphore support.
- pthread rwlock state tracking and support.
- pthread barrier state tracking and support.
- mutexes: support for pthread_mutex_timedlock() (recently added to the POSIX
@@ -42,15 +45,12 @@
Known bugs
~~~~~~~~~~
-- Gets killed by the OOM handler for some applications, e.g. knode and
- OpenOffice.
-- [AMD64] Reports "Allocation context: unknown" for BSS symbols on AMD64
- (works fine on X86). This is a bug in Valgrind's debug info reader
- -- VG_(find_seginfo)() returns NULL for BSS symbols on AMD64. Not yet in
+- Gets killed by the OOM handler for realistically sized applications,
+ e.g. knode and OpenOffice.
+- [x86_64] Reports "Allocation context: unknown" for BSS symbols on AMD64
+ (works fine on i386). This is a bug in Valgrind's debug info reader
+ -- VG_(find_seginfo)() returns NULL for BSS symbols on x86_64. Not yet in
the KDE bug tracking system.
-- False positives are reported when a signal is sent via pthread_kill() from
- one thread to another (bug 152728).
-- Crashes (cause not known): VALGRIND_LIB=$PWD/.in_place coregrind/valgrind --tool=exp-drd --trace-mem=yes /bin/ls
Known performance issues:
- According to cachegrind, VG_(OSet_Next)() is taking up most CPU cycles.
Modified: trunk/exp-drd/docs/Makefile.am
===================================================================
--- trunk/exp-drd/docs/Makefile.am 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/exp-drd/docs/Makefile.am 2007-12-04 21:27:18 UTC (rev 7275)
@@ -1 +1 @@
-#EXTRA_DIST = drd-manual.xml
+EXTRA_DIST = README.txt
Added: trunk/exp-drd/docs/README.txt
===================================================================
--- trunk/exp-drd/docs/README.txt (rev 0)
+++ trunk/exp-drd/docs/README.txt 2007-12-04 21:27:18 UTC (rev 7275)
@@ -0,0 +1,83 @@
+DRD: a Data Race Detector
+=========================
+
+Last update: December 3, 2007 by Bart Van Assche.
+
+
+The Difficulty of Multithreading Programming
+--------------------------------------------
+Multithreading is a concept to model multiple concurrent activities within a
+single process. Since the invention of the multithreading concept, there is an
+ongoing debate about which way to model concurrent activities is better --
+multithreading or message passing. This debate exists because
+multithreaded programming is error prone: multithreaded programs can exhibit
+data races and/or deadlocks. Despite these risks multithreaded programming is
+popular: for many applications multithreading is a more natural programming
+style, and multithreaded code often runs faster than the same application
+implemented via message passing.
+
+In the context of DRD, a data race is defined as two concurrent memory
+accesses, where at least one of these two memory accesses is a store operation,
+and these accesses are not protected by proper locking constructs. Data
+races are harmful because these may lead to unpredictable results in
+multithreaded programs. There is a general consensus that data races
+should be avoided in multithreaded programs.
+
+
+About DRD
+---------
+The current version of DRD is able to perform data race detection on small
+programs -- DRD quickly runs out of memory for realistically sized programs.
+The current version runs well under Linux on x86 CPU's for multithreaded
+programs that use the POSIX threading library. Regular POSIX threads, detached
+threads, mutexes, condition variables and spinlocks are supported. POSIX
+semaphores, barriers and reader-writer locks are not yet supported.
+
+Extensive scientific research has been carried out on the area of data-race
+detection. The two most important algorithms are known as the Eraser algorithm
+and the algorithm based on the happens-before relationship, first documented by
+Netzer. The Eraser algorithm can result in false positives, while the Netzer
+algorithm guarantees not to report false positives. The Netzer algorithm
+ignores a certain class of data races however. Both algorithms have been
+implemented in Valgrind. The helgrind tool implements the Eraser algorithm,
+and the DRD tool implements the Netzer algorithm. Although [Savage 1997]
+claims that the Netzer algorithm is harder to implement efficiently, as of
+version 3.3.0 drd runs significantly faster on several regression tests than
+helgrind.
+
+
+How to use DRD
+--------------
+To use this tool, specify --tool=drd on the Valgrind command line.
+
+
+Future DRD Versions
+-------------------
+The following may be expected in future versions of DRD:
+* More extensive documentation.
+* Drastically reduced memory consumption, such that realistic applications can
+ be analyzed with DRD.
+* Faster operation.
+* Support for semaphores, barriers and reader-writer locks.
+* Support for PowerPC CPU's.
+* A lock dependency analyzer, as a help in deadlock prevention.
+* Support for more than 256 mutexes per process.
+
+
+See also
+--------
+* Robert H. B. Netzer and Barton P. Miller. What are race
+ conditions? Some issues and formalizations. ACM Letters 136
+ on Programming Languages and Systems, 1(1):74–88, March 1992.
+
+* John Ousterhout, Why Threads Are A Bad Idea (for most
+ purposes), Invited Talk at the 1996 USENIX Technical Conference (January
+ 25, 1996). http://home.pacbell.net/ouster/threads.pdf
+
+* Stefan Savage, Michael Burrows, Greg Nelson, Patrick
+ Sobalvarro and Thomas Anderson, Eraser: A Dynamic Data Race Detector for
+ Multithreaded Programs, ACM Transactions on Computer Systems,
+ 15(4):391-411, November 1997.
+
+
+
Modified: trunk/exp-drd/drd_main.c
===================================================================
--- trunk/exp-drd/drd_main.c 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/exp-drd/drd_main.c 2007-12-04 21:27:18 UTC (rev 7275)
@@ -74,23 +74,6 @@
static Bool drd_trace_mem = False;
static Bool drd_trace_fork_join = False;
static Addr drd_trace_address = 0;
-#if 0
-// Note: using the information below for suppressing data races is only
-// possible when the client and the shared libraries it uses contain
-// debug information. Not every Linux distribution includes debug information
-// in shared libraries.
-static const SuppressedSymbol s_suppressed_symbols[] =
- {
- { "ld-linux.so.2", "_rtld_local" },
- { "libpthread.so.0", "__nptl_nthreads" },
- { "libpthread.so.0", "stack_cache" },
- { "libpthread.so.0", "stack_cache_actsize" },
- { "libpthread.so.0", "stack_cache_lock" },
- { "libpthread.so.0", "stack_used" },
- { "libpthread.so.0", "libgcc_s_forcedunwind" },
- { "libpthread.so.0", "libgcc_s_getcfa" },
- };
-#endif
//
@@ -155,6 +138,8 @@
{
Segment* sg;
+ thread_set_vg_running_tid(VG_(get_running_tid)());
+
if (! thread_is_recording(thread_get_running_tid()))
return;
@@ -195,6 +180,8 @@
{
Segment* sg;
+ thread_set_vg_running_tid(VG_(get_running_tid)());
+
if (! thread_is_recording(thread_get_running_tid()))
return;
@@ -237,30 +224,8 @@
const Addr a,
const SizeT size)
{
- const ThreadId running_tid = VG_(get_running_tid)();
-
- if (size == 0)
- return;
-
- if (tid != running_tid)
+ if (size > 0)
{
- if (VgThreadIdToDrdThreadId(tid) != DRD_INVALID_THREADID)
- {
- drd_set_running_tid(tid);
- drd_trace_load(a, size);
- drd_set_running_tid(running_tid);
- }
- else
- {
- VG_(message)(Vg_DebugMsg,
- "drd_pre_mem_read() was called before"
- " drd_post_thread_create() for thread ID %d",
- tid);
- tl_assert(0);
- }
- }
- else
- {
drd_trace_load(a, size);
}
}
@@ -270,38 +235,16 @@
const Addr a,
const SizeT size)
{
- const ThreadId running_tid = VG_(get_running_tid)();
-
- if (size == 0)
- return;
-
- if (tid != running_tid)
+ if (size > 0)
{
- if (VgThreadIdToDrdThreadId(tid) != DRD_INVALID_THREADID)
- {
- drd_set_running_tid(tid);
- drd_trace_store(a, size);
- drd_set_running_tid(running_tid);
- }
- else
- {
-#if 1
- VG_(message)(Vg_DebugMsg,
- "drd_pre_mem_write() was called before"
- " drd_post_thread_create() for thread ID %d",
- tid);
- tl_assert(0);
-#endif
- }
- }
- else
- {
drd_trace_store(a, size);
}
}
static void drd_start_using_mem(const Addr a1, const Addr a2)
{
+ thread_set_vg_running_tid(VG_(get_running_tid)());
+
if (a1 <= drd_trace_address && drd_trace_address < a2
&& thread_is_recording(thread_get_running_tid()))
{
@@ -354,9 +297,7 @@
/* Assumption: stacks grow downward. */
static void drd_stop_using_mem_stack(const Addr a, const SizeT len)
{
-#if 0
- VG_(message)(Vg_DebugMsg, "stop_using_mem_stack(0x%lx, %ld)", a, len);
-#endif
+ thread_set_vg_running_tid(VG_(get_running_tid)());
thread_set_stack_min(thread_get_running_tid(),
a + len - VG_STACK_REDZONE_SZB);
drd_stop_using_mem(a - VG_STACK_REDZONE_SZB,
@@ -384,11 +325,7 @@
// Hack: compensation for code missing in coregrind/m_main.c.
if (created == 1)
{
- extern ThreadId VG_(running_tid);
- tl_assert(VG_(running_tid) == VG_INVALID_THREADID);
- VG_(running_tid) = 1;
- drd_start_client_code(VG_(running_tid), 0);
- VG_(running_tid) = VG_INVALID_THREADID;
+ thread_set_running_tid(1, 1);
}
#endif
if (IsValidDrdThreadId(drd_creator))
@@ -559,10 +496,7 @@
# if defined(VGP_x86_linux) || defined(VGP_amd64_linux)
/* fine */
# else
- VG_(printf)("\nDRD currently only works on x86-linux and amd64-linux.\n");
- VG_(printf)("At the very least you need to set PTHREAD_{MUTEX,COND}_SIZE\n");
- VG_(printf)("in pthread_object_size.h to correct values. Sorry.\n\n");
- VG_(exit)(0);
+ VG_(printf)("\nWARNING: DRD has only been tested on x86-linux and amd64-linux.\n\n");
# endif
}
@@ -696,21 +630,21 @@
return bb;
}
-static void drd_set_running_tid(const ThreadId tid)
+static void drd_set_running_tid(const ThreadId vg_tid)
{
- static ThreadId s_last_tid = VG_INVALID_THREADID;
- if (tid != s_last_tid)
+ static ThreadId s_last_vg_tid = VG_INVALID_THREADID;
+ if (vg_tid != s_last_vg_tid)
{
- const DrdThreadId drd_tid = VgThreadIdToDrdThreadId(tid);
+ const DrdThreadId drd_tid = VgThreadIdToDrdThreadId(vg_tid);
tl_assert(drd_tid != DRD_INVALID_THREADID);
- s_last_tid = tid;
+ s_last_vg_tid = vg_tid;
if (drd_trace_fork_join)
{
VG_(message)(Vg_DebugMsg,
"drd_track_thread_run tid = %d / drd tid %d",
- tid, drd_tid);
+ vg_tid, drd_tid);
}
- thread_set_running_tid(drd_tid);
+ thread_set_running_tid(vg_tid, drd_tid);
}
}
@@ -766,7 +700,7 @@
static const Char drd_supp[] = "glibc-2.X-drd.supp";
const Int len = VG_(strlen)(VG_(libdir)) + 1 + sizeof(drd_supp);
Char* const buf = VG_(arena_malloc)(VG_AR_CORE, len);
- VG_(sprintf)(buf, "%s/%s", VG_(libdir), drd_supp);
+ VG_(snprintf)(buf, len, "%s/%s", VG_(libdir), drd_supp);
VG_(clo_suppressions)[VG_(clo_n_suppressions)] = buf;
VG_(clo_n_suppressions)++;
}
Modified: trunk/exp-drd/drd_thread.c
===================================================================
--- trunk/exp-drd/drd_thread.c 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/exp-drd/drd_thread.c 2007-12-04 21:27:18 UTC (rev 7275)
@@ -84,7 +84,8 @@
static ULong s_update_danger_set_count;
static ULong s_danger_set_bitmap_creation_count;
static ULong s_danger_set_bitmap2_creation_count;
-static DrdThreadId s_running_tid = DRD_INVALID_THREADID;
+static ThreadId s_vg_running_tid = VG_INVALID_THREADID;
+static DrdThreadId s_drd_running_tid = DRD_INVALID_THREADID;
static ThreadInfo s_threadinfo[DRD_N_THREADS];
static struct bitmap* s_danger_set;
@@ -420,19 +421,51 @@
fmt, arg);
s_threadinfo[tid].name[sizeof(s_threadinfo[tid].name) - 1] = 0;
}
+
DrdThreadId thread_get_running_tid(void)
{
- tl_assert(s_running_tid != DRD_INVALID_THREADID);
- return s_running_tid;
+ // HACK. To do: remove the if-statement and keep the assert.
+ if (VG_(get_running_tid)() != VG_INVALID_THREADID)
+ tl_assert(VG_(get_running_tid)() == s_vg_running_tid);
+ tl_assert(s_drd_running_tid != DRD_INVALID_THREADID);
+ return s_drd_running_tid;
}
-void thread_set_running_tid(const DrdThreadId tid)
+void thread_set_vg_running_tid(const ThreadId vg_tid)
{
- s_running_tid = tid;
- thread_update_danger_set(tid);
- s_context_switch_count++;
+ // HACK. To do: uncomment the line below.
+ // tl_assert(vg_tid != VG_INVALID_THREADID);
+
+ if (vg_tid != s_vg_running_tid)
+ {
+ thread_set_running_tid(vg_tid, VgThreadIdToDrdThreadId(vg_tid));
+ }
+
+ tl_assert(s_vg_running_tid != VG_INVALID_THREADID);
+ tl_assert(s_drd_running_tid != DRD_INVALID_THREADID);
}
+void thread_set_running_tid(const ThreadId vg_tid, const DrdThreadId drd_tid)
+{
+ // HACK. To do: remove the next two lines.
+ if (vg_tid == VG_INVALID_THREADID)
+ return;
+
+ tl_assert(vg_tid != VG_INVALID_THREADID);
+ tl_assert(drd_tid != DRD_INVALID_THREADID);
+
+ if (vg_tid != s_vg_running_tid)
+ {
+ s_vg_running_tid = vg_tid;
+ s_drd_running_tid = drd_tid;
+ thread_update_danger_set(drd_tid);
+ s_context_switch_count++;
+ }
+
+ tl_assert(s_vg_running_tid != VG_INVALID_THREADID);
+ tl_assert(s_drd_running_tid != DRD_INVALID_THREADID);
+}
+
/**
* Return a pointer to the latest segment for the specified thread.
*/
@@ -640,7 +673,7 @@
vc_combine(&s_threadinfo[joiner].last->vc, &s_threadinfo[joinee].last->vc);
thread_discard_ordered_segments();
- if (joiner == s_running_tid)
+ if (joiner == s_drd_running_tid)
{
thread_update_danger_set(joiner);
}
@@ -668,7 +701,7 @@
for (p = s_threadinfo[i].first; p; p = p->next)
{
if (other_user == DRD_INVALID_THREADID
- && i != s_running_tid
+ && i != s_drd_running_tid
&& bm_has_any_access(p->bm, a1, a2))
{
other_user = i;
@@ -939,7 +972,7 @@
tl_assert(0 <= tid && tid < DRD_N_THREADS
&& tid != DRD_INVALID_THREADID);
- tl_assert(tid == s_running_tid);
+ tl_assert(tid == s_drd_running_tid);
s_update_danger_set_count++;
s_danger_set_bitmap_creation_count -= bm_get_bitmap_creation_count();
Modified: trunk/exp-drd/drd_thread.h
===================================================================
--- trunk/exp-drd/drd_thread.h 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/exp-drd/drd_thread.h 2007-12-04 21:27:18 UTC (rev 7275)
@@ -70,7 +70,9 @@
void thread_set_name_fmt(const DrdThreadId tid, const char* const name,
const UWord arg);
DrdThreadId thread_get_running_tid(void);
-void thread_set_running_tid(const DrdThreadId tid);
+void thread_set_vg_running_tid(const ThreadId vg_tid);
+void thread_set_running_tid(const ThreadId vg_tid,
+ const DrdThreadId drd_tid);
Segment* thread_get_segment(const DrdThreadId tid);
void thread_new_segment(const DrdThreadId tid);
VectorClock* thread_get_vc(const DrdThreadId tid);
Modified: trunk/exp-drd/tests/pth_create_chain.vgtest
===================================================================
--- trunk/exp-drd/tests/pth_create_chain.vgtest 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/exp-drd/tests/pth_create_chain.vgtest 2007-12-04 21:27:18 UTC (rev 7275)
@@ -1 +1 @@
-prog: pth_create_chain 10
+prog: pth_create_chain 100
Modified: trunk/glibc-2.X-drd.supp
===================================================================
--- trunk/glibc-2.X-drd.supp 2007-12-04 21:18:06 UTC (rev 7274)
+++ trunk/glibc-2.X-drd.supp 2007-12-04 21:27:18 UTC (rev 7275)
@@ -20,29 +20,29 @@
fun:exit
}
{
- dl
+ dl-2.6.*
exp-drd:ConflictingAccess
- obj:/lib64/ld-2.6.1.so
+ obj:/lib*/ld-*.so
fun:exit
}
{
- dl-2.6.1
+ dl-2.6.*
exp-drd:ConflictingAccess
- obj:/lib64/ld-2.6.1.so
- obj:/lib64/ld-2.6.1.so
- obj:/lib64/ld-2.6.1.so
+ obj:/lib*/ld-*.so
+ obj:/lib*/ld-*.so
+ obj:/lib*/ld-*.so
}
{
libc
exp-drd:ConflictingAccess
fun:__libc_enable_asynccancel
- obj:/lib/libc-*
+ obj:/lib*/libc-*
}
{
libc
exp-drd:ConflictingAccess
fun:__libc_disable_asynccancel
- obj:/lib/libc-*
+ obj:/lib*/libc-*
}
{
librt
@@ -78,14 +78,14 @@
{
pthread
exp-drd:ConflictingAccess
- obj:/lib64/libpthread-2.6.1.so
+ obj:/lib*/libpthread-*.so
fun:start_thread
fun:clone
}
{
pthread
exp-drd:ConflictingAccess
- obj:/lib64/libc-2.6.1.so
+ obj:/lib*/libc-*.so
fun:__libc_thread_freeres
fun:start_thread
fun:clone
@@ -93,8 +93,8 @@
{
pthread
exp-drd:ConflictingAccess
- obj:/lib64/libc-2.6.1.so
- obj:/lib64/libc-2.6.1.so
+ obj:/lib*/libc-*.so
+ obj:/lib*/libc-*.so
fun:__libc_thread_freeres
fun:start_thread
fun:clone
@@ -157,6 +157,14 @@
{
pthread
exp-drd:ConflictingAccess
+ fun:free_stacks
+ fun:__deallocate_stack
+ fun:pthread_join
+ fun:pthread_join
+}
+{
+ pthread
+ exp-drd:ConflictingAccess
fun:__free_tcb
}
{
@@ -193,7 +201,7 @@
pthread
exp-drd:ConflictingAccess
fun:sigcancel_handler
- obj:/lib/libpthread-*
+ obj:/lib*/libpthread-*
}
{
pthread-unwind
@@ -201,7 +209,7 @@
fun:_Unwind_ForcedUnwind
fun:__pthread_unwind
fun:sigcancel_handler
- obj:/lib/libpthread-*
+ obj:/lib*/libpthread-*
}
{
pthread-unwind
|
|
From: <sv...@va...> - 2007-12-04 21:18:05
|
Author: njn
Date: 2007-12-04 21:18:06 +0000 (Tue, 04 Dec 2007)
New Revision: 7274
Log:
Remove client requests that were deprecated in 3.2.0.
Modified:
trunk/NEWS
trunk/memcheck/memcheck.h
trunk/memcheck/tests/leak-pool.c
trunk/memcheck/tests/sh-mem-random.c
Modified: trunk/NEWS
===================================================================
--- trunk/NEWS 2007-12-04 16:12:54 UTC (rev 7273)
+++ trunk/NEWS 2007-12-04 21:18:06 UTC (rev 7274)
@@ -128,6 +128,16 @@
they just return 3 (as before). Also, SET_VBITS doesn't report
definedness errors if any of the V bits are undefined.
+- The following Memcheck client requests have been removed:
+ VALGRIND_MAKE_NOACCESS
+ VALGRIND_MAKE_WRITABLE
+ VALGRIND_MAKE_READABLE
+ VALGRIND_CHECK_WRITABLE
+ VALGRIND_CHECK_READABLE
+ VALGRIND_CHECK_DEFINED
+ They were deprecated in 3.2.0, when equivalent but better-named client
+ requests were added. See the 3.2.0 release notes for more details.
+
- The behaviour of the tool Lackey has changed slightly. First, the output
from --trace-mem has been made more compact, to reduce the size of the
traces. Second, a new option --trace-superblocks has been added, which
Modified: trunk/memcheck/memcheck.h
===================================================================
--- trunk/memcheck/memcheck.h 2007-12-04 16:12:54 UTC (rev 7273)
+++ trunk/memcheck/memcheck.h 2007-12-04 21:18:06 UTC (rev 7274)
@@ -131,18 +131,6 @@
_qzz_res; \
}))
-/* This is the old name for VALGRIND_MAKE_MEM_NOACCESS. Deprecated. */
-#define VALGRIND_MAKE_NOACCESS(_qzz_addr,_qzz_len) \
- VALGRIND_MAKE_MEM_NOACCESS(_qzz_addr,_qzz_len)
-
-/* This is the old name for VALGRIND_MAKE_MEM_UNDEFINED. Deprecated. */
-#define VALGRIND_MAKE_WRITABLE(_qzz_addr,_qzz_len) \
- VALGRIND_MAKE_MEM_UNDEFINED(_qzz_addr,_qzz_len)
-
-/* This is the old name for VALGRIND_MAKE_MEM_DEFINED. Deprecated. */
-#define VALGRIND_MAKE_READABLE(_qzz_addr,_qzz_len) \
- VALGRIND_MAKE_MEM_DEFINED(_qzz_addr,_qzz_len)
-
/* Similar to VALGRIND_MAKE_MEM_DEFINED except that addressability is
not altered: bytes which are addressable are marked as defined,
but those which are not addressable are left unchanged. */
@@ -214,19 +202,7 @@
(volatile unsigned char *)&(__lvalue), \
(unsigned int)(sizeof (__lvalue)))
-/* This is the old name for VALGRIND_CHECK_MEM_IS_ADDRESSABLE. Deprecated. */
-#define VALGRIND_CHECK_WRITABLE(_qzz_addr,_qzz_len) \
- VALGRIND_CHECK_MEM_IS_ADDRESSABLE(_qzz_addr,_qzz_len)
-/* This is the old name for VALGRIND_CHECK_MEM_IS_DEFINED. Deprecated. */
-#define VALGRIND_CHECK_READABLE(_qzz_addr,_qzz_len) \
- VALGRIND_CHECK_MEM_IS_DEFINED(_qzz_addr,_qzz_len)
-
-/* This is the old name for VALGRIND_CHECK_VALUE_IS_DEFINED. Deprecated. */
-#define VALGRIND_CHECK_DEFINED(__lvalue) \
- VALGRIND_CHECK_VALUE_IS_DEFINED(__lvalue)
-
-
/* Do a memory leak check mid-execution. */
#define VALGRIND_DO_LEAK_CHECK \
{unsigned int _qzz_res; \
Modified: trunk/memcheck/tests/leak-pool.c
===================================================================
--- trunk/memcheck/tests/leak-pool.c 2007-12-04 16:12:54 UTC (rev 7273)
+++ trunk/memcheck/tests/leak-pool.c 2007-12-04 21:18:06 UTC (rev 7274)
@@ -40,7 +40,7 @@
assert(p->buf);
memset(p->buf, 0, p->allocated);
VALGRIND_CREATE_MEMPOOL(p, 0, 0);
- VALGRIND_MAKE_NOACCESS(p->buf, p->allocated);
+ VALGRIND_MAKE_MEM_NOACCESS(p->buf, p->allocated);
return p;
}
Modified: trunk/memcheck/tests/sh-mem-random.c
===================================================================
--- trunk/memcheck/tests/sh-mem-random.c 2007-12-04 16:12:54 UTC (rev 7273)
+++ trunk/memcheck/tests/sh-mem-random.c 2007-12-04 21:18:06 UTC (rev 7274)
@@ -40,7 +40,7 @@
U8 mask = 0;
U8 shres;
U8 res = 0xffffffffffffffffULL, res2;
- VALGRIND_MAKE_WRITABLE(&res, 8);
+ VALGRIND_MAKE_MEM_UNDEFINED(&res, 8);
assert(1 == size || 2 == size || 4 == size || 8 == size);
for (i = 0; i < size; i++) {
@@ -55,7 +55,7 @@
VALGRIND_GET_VBITS(&res, &shres, 8);
res2 = res;
- VALGRIND_MAKE_READABLE(&res2, 8); // avoid the 'undefined' warning
+ VALGRIND_MAKE_MEM_DEFINED(&res2, 8); // avoid the 'undefined' warning
assert(res2 == shres);
return res;
}
@@ -63,7 +63,7 @@
U1 make_defined ( U1 x )
{
volatile U1 xx = x;
- VALGRIND_MAKE_READABLE(&xx, 1);
+ VALGRIND_MAKE_MEM_DEFINED(&xx, 1);
return xx;
}
|
|
From: Julian S. <js...@ac...> - 2007-12-04 19:49:07
|
> > All these optimised, vectorised (effectively) string ops rely on two > > techniques: > > > > (1) using properties of carry-chain propagation in addition/subtraction > > so as find out whether any byte in a word is zero, and if so > > which one > > Do you mean the well know and widely use technique: [..] Yes. > note that in GLIBC the even the default generic implementation strlen.c > uses this trick. Yes. So Memcheck intercepts strlen et al in glibc. > Yup. On processors with wide registers and multiple Load/Store and FixPoint > units it would criminally negligent not to do this. Also you will be see a > lot more speculative loads in both hand tuned code and with GCC-4.3 > (Auto-vectorization and auto-parallelization). This applies to POWER > (Altivec) and x86(_64) (SSE4). In hand tuned code, perhaps. I would be surprised to see overruns in autovectorised code, since compilers tend only to vectorise loops for which the trip count is known at run time before the loop starts, and so generate a vector loop and a following fixup loop to handle any leftover iterations. So the vector loop doesn't overrun memory. > > * do not strip all symbol names off ld.so > > This is not really our call! You are going after LOCAL symbols which are > only needed for debug (not needed at run-time). The distros can strip > libraries to save space on the ISO images, so they do. The one concession > they make is to provide the debug-info images. In the end I simply arranged for Memcheck on ppc32/64-linux to check for the presence of the relevant symbols in ld.so, and crap out if they are not present, printing a message advising the user to install the debuginfo image. J |
|
From: <sv...@va...> - 2007-12-04 19:04:18
|
Author: sewardj
Date: 2007-12-04 19:04:17 +0000 (Tue, 04 Dec 2007)
New Revision: 1804
Log:
Generate code to handle 64-bit integer loads and stores on 32-bit
targets, as this is needed by Massif in Valgrind 3.3.0.
Modified:
trunk/priv/host-ppc/isel.c
Modified: trunk/priv/host-ppc/isel.c
===================================================================
--- trunk/priv/host-ppc/isel.c 2007-11-27 00:11:13 UTC (rev 1803)
+++ trunk/priv/host-ppc/isel.c 2007-12-04 19:04:17 UTC (rev 1804)
@@ -2552,6 +2552,23 @@
vassert(e);
vassert(typeOfIRExpr(env->type_env,e) == Ity_I64);
+ /* 64-bit load */
+ if (e->tag == Iex_Load) {
+ HReg tLo = newVRegI(env);
+ HReg tHi = newVRegI(env);
+ HReg r_addr = iselWordExpr_R(env, e->Iex.Load.addr);
+ vassert(!env->mode64);
+ addInstr(env, PPCInstr_Load( 4/*byte-load*/,
+ tHi, PPCAMode_IR( 0, r_addr ),
+ False/*32-bit insn please*/) );
+ addInstr(env, PPCInstr_Load( 4/*byte-load*/,
+ tLo, PPCAMode_IR( 4, r_addr ),
+ False/*32-bit insn please*/) );
+ *rHi = tHi;
+ *rLo = tLo;
+ return;
+ }
+
/* 64-bit literal */
if (e->tag == Iex_Const) {
ULong w64 = e->Iex.Const.con->Ico.U64;
@@ -3668,7 +3685,6 @@
/* --------- STORE --------- */
case Ist_Store: {
- PPCAMode* am_addr;
IRType tya = typeOfIRExpr(env->type_env, stmt->Ist.Store.addr);
IRType tyd = typeOfIRExpr(env->type_env, stmt->Ist.Store.data);
IREndness end = stmt->Ist.Store.end;
@@ -3678,32 +3694,56 @@
( mode64 && (tya != Ity_I64)) )
goto stmt_fail;
- am_addr = iselWordExpr_AMode(env, stmt->Ist.Store.addr, tyd/*of xfer*/);
if (tyd == Ity_I8 || tyd == Ity_I16 || tyd == Ity_I32 ||
(mode64 && (tyd == Ity_I64))) {
+ PPCAMode* am_addr
+ = iselWordExpr_AMode(env, stmt->Ist.Store.addr, tyd/*of xfer*/);
HReg r_src = iselWordExpr_R(env, stmt->Ist.Store.data);
addInstr(env, PPCInstr_Store( toUChar(sizeofIRType(tyd)),
- am_addr, r_src, mode64 ));
+ am_addr, r_src, mode64 ));
return;
}
if (tyd == Ity_F64) {
+ PPCAMode* am_addr
+ = iselWordExpr_AMode(env, stmt->Ist.Store.addr, tyd/*of xfer*/);
HReg fr_src = iselDblExpr(env, stmt->Ist.Store.data);
addInstr(env,
PPCInstr_FpLdSt(False/*store*/, 8, fr_src, am_addr));
return;
}
if (tyd == Ity_F32) {
+ PPCAMode* am_addr
+ = iselWordExpr_AMode(env, stmt->Ist.Store.addr, tyd/*of xfer*/);
HReg fr_src = iselFltExpr(env, stmt->Ist.Store.data);
addInstr(env,
PPCInstr_FpLdSt(False/*store*/, 4, fr_src, am_addr));
return;
}
if (tyd == Ity_V128) {
+ PPCAMode* am_addr
+ = iselWordExpr_AMode(env, stmt->Ist.Store.addr, tyd/*of xfer*/);
HReg v_src = iselVecExpr(env, stmt->Ist.Store.data);
addInstr(env,
PPCInstr_AvLdSt(False/*store*/, 16, v_src, am_addr));
return;
}
+ if (tyd == Ity_I64 && !mode64) {
+ /* Just calculate the address in the register. Life is too
+ short to arse around trying and possibly failing to adjust
+ the offset in a 'reg+offset' style amode. */
+ HReg rHi32, rLo32;
+ HReg r_addr = iselWordExpr_R(env, stmt->Ist.Store.addr);
+ iselInt64Expr( &rHi32, &rLo32, env, stmt->Ist.Store.data );
+ addInstr(env, PPCInstr_Store( 4/*byte-store*/,
+ PPCAMode_IR( 0, r_addr ),
+ rHi32,
+ False/*32-bit insn please*/) );
+ addInstr(env, PPCInstr_Store( 4/*byte-store*/,
+ PPCAMode_IR( 4, r_addr ),
+ rLo32,
+ False/*32-bit insn please*/) );
+ return;
+ }
break;
}
|
|
From: Julian S. <js...@ac...> - 2007-12-04 17:45:08
|
> > In short there's a conflict between optimising the hell out of stringops > > and having enough visibility for reliable debugging. Given the above > > constraints I don't see how you can have your cake and eat it. > > Unfortunately this conflicts with using Valgrind for other useful functions > like instruction trace. If you arbitrarily substitute your own string > functions, the trace is invalid. There is no conflict in the insn trace (etc) case. The intercepts I mention only apply to Memcheck, not to any of the other tools. J |
|
From: <sv...@va...> - 2007-12-04 16:13:03
|
Author: sewardj
Date: 2007-12-04 16:12:54 +0000 (Tue, 04 Dec 2007)
New Revision: 7273
Log:
Handle semaphore-related syscalls.
Modified:
trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c
Modified: trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c 2007-12-04 10:09:24 UTC (rev 7272)
+++ trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c 2007-12-04 16:12:54 UTC (rev 7273)
@@ -661,6 +661,7 @@
AIXX_(__NR_AIX5__pause, sys__pause),
AIXXY(__NR_AIX5__poll, sys__poll),
AIXX_(__NR_AIX5__select, sys__select),
+ AIXX_(__NR_AIX5__sem_wait, sys__sem_wait),
AIXXY(__NR_AIX5__sigaction, sys__sigaction),
AIXX_(__NR_AIX5__thread_self, sys__thread_self),
AIXX_(__NR_AIX5_access, sys_access),
@@ -721,6 +722,8 @@
AIXX_(__NR_AIX5_privcheck, sys_privcheck),
AIXX_(__NR_AIX5_rename, sys_rename),
AIXXY(__NR_AIX5_sbrk, sys_sbrk),
+ AIXXY(__NR_AIX5_sem_init, sys_sem_init),
+ AIXXY(__NR_AIX5_sem_post, sys_sem_post),
AIXX_(__NR_AIX5_send, sys_send),
AIXX_(__NR_AIX5_setgid, sys_setgid),
AIXX_(__NR_AIX5_setsockopt, sys_setsockopt),
|
|
From: <sv...@va...> - 2007-12-04 10:09:21
|
Author: weidendo
Date: 2007-12-04 10:09:24 +0000 (Tue, 04 Dec 2007)
New Revision: 7272
Log:
Update old (and wrong) parts of callgrind documentation.
This obviously was already wrong in 3.2.x :-(
* Old --fn-recursion=... / --fn-caller=... options are called
--separate-recs=... / --separate-callers=... since quite some
time for consistency with e.g. --separate-threads=yes.
Error noted from bug 153335.
* Function specifications support wildcards since quite some time;
specification of a prefix only does not work, but the full
function has to match. This was needed to allow to specify 'foo'
without also specifying 'foo1'.
* The script 'callgrind' does not exist since merging into
valgrind.
* Rename callgrind from being a 'heavyweight' to a 'call graph'
profiler, similar to the description in the quick start overview.
Modified:
trunk/callgrind/docs/cl-manual.xml
Modified: trunk/callgrind/docs/cl-manual.xml
===================================================================
--- trunk/callgrind/docs/cl-manual.xml 2007-12-04 03:27:40 UTC (rev 7271)
+++ trunk/callgrind/docs/cl-manual.xml 2007-12-04 10:09:24 UTC (rev 7272)
@@ -4,13 +4,13 @@
[ <!ENTITY % cl-entities SYSTEM "cl-entities.xml"> %cl-entities; ]>
<chapter id="cl-manual" xreflabel="Callgrind Manual">
-<title>Callgrind: a heavyweight profiler</title>
+<title>Callgrind: a call graph profiler</title>
<sect1 id="cl-manual.use" xreflabel="Overview">
<title>Overview</title>
-<para>Callgrind is profiling tool that can
+<para>Callgrind is a profiling tool that can
construct a call graph for a program's run.
By default, the collected data consists of
the number of instructions executed, their relationship
@@ -65,7 +65,7 @@
<para>Cachegrind collects flat profile data: event counts (data reads,
cache misses, etc.) are attributed directly to the function they
-occurred in. This simple cost attribution mechanism is sometimes
+occurred in. This cost attribution mechanism is
called <emphasis>self</emphasis> or <emphasis>exclusive</emphasis>
attribution.</para>
@@ -115,7 +115,7 @@
(the -g flag), but with optimization turned on.</para>
<para>To start a profile run for a program, execute:
- <screen>callgrind [callgrind options] your-program [program options]</screen>
+ <screen>valgrind --tool=callgrind [callgrind options] your-program [program options]</screen>
</para>
<para>While the simulation is running, you can observe execution with
@@ -277,16 +277,17 @@
</listitem>
<listitem>
- <para><command>Dumping at enter/leave of all functions whose name
- starts with</command> <emphasis>funcprefix</emphasis>. Use the
- option <option><xref linkend="opt.dump-before"/>=funcprefix</option>
- and <option><xref linkend="opt.dump-after"/>=funcprefix</option>.
+ <para><command>Dumping at enter/leave of specified functions.</command>
+ Use the
+ option <option><xref linkend="opt.dump-before"/>=function</option>
+ and <option><xref linkend="opt.dump-after"/>=function</option>.
To zero cost counters before entering a function, use
- <option><xref linkend="opt.zero-before"/>=funcprefix</option>.
- The prefix method for specifying function names was chosen to
- ease the use with C++: you don't have to specify full
- signatures.</para> <para>You can specify these options multiple
- times for different function prefixes.</para>
+ <option><xref linkend="opt.zero-before"/>=function</option>.</para>
+ <para>You can specify these options multiple times for different
+ functions. Function specifications support wildcards: eg. use
+ <option><xref linkend="opt.dump-before"/>='foo*'</option> to
+ generate dumps before entering any function starting with
+ <emphasis>foo</emphasis>.</para>
</listitem>
<listitem>
@@ -344,17 +345,15 @@
<para>In addition to enabling instrumentation, you must also enable
event collection for the parts of your program you are interested in.
By default, event collection is enabled everywhere.
- You can limit collection to specific function(s)
+ You can limit collection to a specific function
by using
- <option><xref linkend="opt.toggle-collect"/>=funcprefix</option>.
+ <option><xref linkend="opt.toggle-collect"/>=function</option>.
This will toggle the collection state on entering and leaving
the specified functions.
When this option is in effect, the default collection state
at program start is "off". Only events happening while running
- inside of functions starting with <emphasis>funcprefix</emphasis> will
- be collected. Recursive
- calls of functions with <emphasis>funcprefix</emphasis> do not trigger
- any action.</para>
+ inside of the given function will be collected. Recursive
+ calls of the given function do not trigger any action.</para>
<para>It is important to note that with instrumentation switched off, the
cache simulator cannot see any memory access events, and thus, any
@@ -441,7 +440,7 @@
also skips any call information from and to an ignored function, and thus can
break a cycle. Candidates for this typically are dispatcher functions in event
driven code. The option to ignore calls to a function is
- <option><xref linkend="opt.fn-skip"/>=funcprefix</option>. Aside from
+ <option><xref linkend="opt.fn-skip"/>=function</option>. Aside from
possibly breaking cycles, this is used in Callgrind to skip
trampoline functions in the PLT sections
for calls to functions in shared libraries. You can see the difference
@@ -451,22 +450,22 @@
<para>If you have a recursive function, you can distinguish the first
10 recursion levels by specifying
- <option><xref linkend="opt.fn-recursion-num"/>=funcprefix</option>.
+ <option><xref linkend="opt.separate-recs-num"/>=function</option>.
Or for all functions with
- <option><xref linkend="opt.fn-recursion"/>=10</option>, but this will
+ <option><xref linkend="opt.separate-recs"/>=10</option>, but this will
give you much bigger profile data files. In the profile data, you will see
the recursion levels of "func" as the different functions with names
"func", "func'2", "func'3" and so on.</para>
<para>If you have call chains "A > B > C" and "A > C > B"
in your program, you usually get a "false" cycle "B <> C". Use
- <option><xref linkend="opt.fn-caller-num"/>=B</option>
- <option><xref linkend="opt.fn-caller-num"/>=C</option>,
+ <option><xref linkend="opt.separate-callers-num"/>=B</option>
+ <option><xref linkend="opt.separate-callers-num"/>=C</option>,
and functions "B" and "C" will be treated as different functions
depending on the direct caller. Using the apostrophe for appending
this "context" to the function name, you get "A > B'A > C'B"
and "A > C'A > B'C", and there will be no cycle. Use
- <option><xref linkend="opt.fn-caller"/>=3</option> to get a 2-caller
+ <option><xref linkend="opt.separate-callers"/>=2</option> to get a 2-caller
dependency for all functions. Note that doing this will increase
the size of profile data files.</para>
@@ -479,9 +478,20 @@
<title>Command line option reference</title>
<para>
-In the following, options are grouped into classes, in same order as
-the output as <computeroutput>callgrind --help</computeroutput>.
+In the following, options are grouped into classes, in the same order as
+the output of <computeroutput>callgrind --help</computeroutput>.
</para>
+<para>
+Some options allow the specification of a function/symbol name, such as
+<option><xref linkend="opt.dump-before"/>=function</option>, or
+<option><xref linkend="opt.fn-skip"/>=function</option>. All these options
+can be specified multiple times for different functions.
+In addition, the function specifications actually are patterns by supporting
+the use of wildcards '*' (zero or more arbitrary characters) and '?'
+(exactly one arbitrary character), similar to file name globbing in the
+shell. This feature is important especially for C++, as without wildcard
+usage, the function would have to be specified in full extent, including
+parameter signature. </para>
<sect2 id="cl-manual.options.misc"
xreflabel="Miscellaneous options">
@@ -626,28 +636,28 @@
<varlistentry id="opt.dump-before" xreflabel="--dump-before">
<term>
- <option><![CDATA[--dump-before=<prefix> ]]></option>
+ <option><![CDATA[--dump-before=<function> ]]></option>
</term>
<listitem>
- <para>Dump when entering a function starting with <prefix></para>
+ <para>Dump when entering <function></para>
</listitem>
</varlistentry>
<varlistentry id="opt.zero-before" xreflabel="--zero-before">
<term>
- <option><![CDATA[--zero-before=<prefix> ]]></option>
+ <option><![CDATA[--zero-before=<function> ]]></option>
</term>
<listitem>
- <para>Zero all costs when entering a function starting with <prefix></para>
+ <para>Zero all costs when entering <function></para>
</listitem>
</varlistentry>
<varlistentry id="opt.dump-after" xreflabel="--dump-after">
<term>
- <option><![CDATA[--dump-after=<prefix> ]]></option>
+ <option><![CDATA[--dump-after=<function> ]]></option>
</term>
<listitem>
- <para>Dump when leaving a function starting with <prefix></para>
+ <para>Dump when leaving <function></para>
</listitem>
</varlistentry>
@@ -735,12 +745,10 @@
<varlistentry id="opt.toggle-collect" xreflabel="--toggle-collect">
<term>
- <option><![CDATA[--toggle-collect=<prefix> ]]></option>
+ <option><![CDATA[--toggle-collect=<function> ]]></option>
</term>
<listitem>
- <para>Toggle collection on entry/exit of a function whose name
- starts with
- <prefix>.</para>
+ <para>Toggle collection on entry/exit of <function>.</para>
</listitem>
</varlistentry>
@@ -784,9 +792,9 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.fn-recursion" xreflabel="--fn-recursion">
+ <varlistentry id="opt.separate-recs" xreflabel="--separate-recs">
<term>
- <option><![CDATA[--fn-recursion=<level> [default: 2] ]]></option>
+ <option><![CDATA[--separate-recs=<level> [default: 2] ]]></option>
</term>
<listitem>
<para>Separate function recursions by at most <level> levels.
@@ -794,9 +802,9 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.fn-caller" xreflabel="--fn-caller">
+ <varlistentry id="opt.separate-callers" xreflabel="--separate-callers">
<term>
- <option><![CDATA[--fn-caller=<callers> [default: 0] ]]></option>
+ <option><![CDATA[--separate-callers=<callers> [default: 0] ]]></option>
</term>
<listitem>
<para>Separate contexts by at most <callers> functions in the
@@ -844,9 +852,9 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.fn-recursion-num" xreflabel="--fn-recursion10">
+ <varlistentry id="opt.separate-recs-num" xreflabel="--separate-recs10">
<term>
- <option><![CDATA[--fn-recursion<number>=<function> ]]></option>
+ <option><![CDATA[--separate-recs<number>=<function> ]]></option>
</term>
<listitem>
<para>Separate <number> recursions for <function>.
@@ -854,9 +862,9 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.fn-caller-num" xreflabel="--fn-caller2">
+ <varlistentry id="opt.separate-callers-num" xreflabel="--separate-callers2">
<term>
- <option><![CDATA[--fn-caller<number>=<function> ]]></option>
+ <option><![CDATA[--separate-callers<number>=<function> ]]></option>
</term>
<listitem>
<para>Separate <number> callers for <function>.
|
|
From: Tom H. <th...@cy...> - 2007-12-04 03:56:44
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-04 03:15:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 321 tests, 62 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-04 03:32:14
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-04 03:05:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-04 03:26:45
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-04 03:10:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 10 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-04 03:13:48
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-04 03:00:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 357 tests, 25 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Julian S. <js...@ac...> - 2007-12-04 02:36:28
|
On Monday 03 December 2007 20:29, Dave Nomura wrote:
> So you tracked down these unitialized values down to the strxxx
> functions defined in ld.so and Valgrind normally intercepts these calls
> because Memcheck can't handle the sorts of code that is generated for
> these routines?
Correct.
> Is it possible to teach Memcheck to deal with these optimizations?
>
> Steve Munroe, the author of those optimized strxxx functions, tells me
> that the kinds of optimizations done for these routines are going to
> start appearing in other library routines, and possibly in generated
> object code so the problem is going to become more pervasive.
You're in the land of difficult tradeoffs. A lot of effort has
already been applied here.
All these optimised, vectorised (effectively) string ops rely on two
techniques:
(1) using properties of carry-chain propagation in addition/subtraction
so as find out whether any byte in a word is zero, and if so
which one
(2) reading (traditional C-style zero-terminated) strings using
aligned word reads, rather than byte reads
(1) fools Memcheck's normal handling of definedness tracking for
adds/subtracts, causing it to believe the result of the add/subtract
is completely undefined, when it isn't really. In fact Memcheck
can and sometimes does generate a more exact interpretation, which
does handle this case correctly.
The problem is deciding when to apply it. The standard analysis
costs about 3 insns in the generated code, and the exact analysis
more than 10 insns (+ more registers). Applying the expensive case
throughout would cause significant slowdowns to the 99.99% of code
fragments for which the standard handling is perfectly adequate.
(2) causes Memcheck to report invalid address errors for the partial
word loads covering the zero terminating bytes at the end of
strings. You can stop it complaining about this by giving
--partial-loads-ok=yes, but that could cause genuine errors to
be missed. Said flag is not enabled by default.
I realise that (2) is "perfectly safe" in that the word-sized loads
are naturally aligned and so cannot possibly cause any page faults
that would not otherwise occur. Nevertheless, any way you slice it,
ISO C/C++ says that reading memory outside of allocated blocks
counts as undefined behaviour (IIUC), and that's precisely what
Memcheck aims to report.
We have never claimed that Memcheck is suitable for code compiled at
-O2 and above. -O is the max recommended level. I would advocate the
following:
* do not allow gcc to inline stringops at -O, only at -O2 and above
* do not strip all symbol names off ld.so
In short there's a conflict between optimising the hell out of stringops
and having enough visibility for reliable debugging. Given the above
constraints I don't see how you can have your cake and eat it.
Note that none of the above is PPC specific -- it also applies to
x86/amd64. I'm not sure why these problems appear more acute on ppc
-- it may be some interaction between the carry chain propagation
games and the fact that ppc is bigendian.
J
|
|
From: Julian S. <js...@ac...> - 2007-12-04 02:00:13
|
Hi Josef > attached is a documentation-only patch for callgrind against trunk, > as committing to trunk is deprecated at the moment. This was noted > today while answering the bug report 153335. That seems fine. Please commit. J |
|
From: Julian S. <js...@ac...> - 2007-12-04 01:57:39
|
On Monday 03 December 2007 21:37, Dirk Mueller wrote: > On Monday 03 December 2007, Julian Seward wrote: > > Please test it on platforms that are important to you, and let me know > > of any problems (and successes!). If no serious problems show up, > > 3.3.0 final will be available in about a week from now. > > the patch below does no longer apply. it is in the openSUSE package for > mono support. I was told that it is being upstreamed, but I can't find it > in trunk. Did it get lost? Was it rejected? Dirk, hi. Sorry about that. I have it in private email from the Mono people, but forgot about it. It never made it into bugzilla. I'll look more at it and commit it in the next day or so -- looks OK to me. J |
|
From: <js...@ac...> - 2007-12-04 01:24:02
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-04 02:00:01 CET Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 288 tests, 27 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 288 tests, 27 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/res_search (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Dec 4 02:12:03 2007 --- new.short Tue Dec 4 02:23:09 2007 *************** *** 18,20 **** none/tests/mremap2 (stdout) - none/tests/res_search (stdout) helgrind/tests/hg02_deadlock (stderr) --- 18,19 ---- *************** *** 27,28 **** --- 26,28 ---- helgrind/tests/tc07_hbl1 (stderr) + helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) |