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
(7) |
3
(15) |
4
(14) |
|
5
(12) |
6
(18) |
7
(16) |
8
(13) |
9
(14) |
10
(20) |
11
(26) |
|
12
(14) |
13
(25) |
14
(20) |
15
(15) |
16
(14) |
17
(13) |
18
(12) |
|
19
(8) |
20
(16) |
21
(15) |
22
(37) |
23
(15) |
24
(18) |
25
(12) |
|
26
(8) |
27
(13) |
28
(12) |
|
|
|
|
|
From: <js...@ac...> - 2006-02-25 09:53:41
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-25 02:00:01 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 == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Eric P. <eri...@wa...> - 2006-02-25 09:18:16
|
A summary of where we stand for making Valgrind and Wine work well
together. The starting point is V 3.1.0 and Wine 0.9.7.
First of all (reminder) V & Wine now work (mostly) out of the box together.
Here's a list of (known) problems faced:
a/ missing support for some ioctl's (HDMA, serial). Added to V (now in
branch, at least of x86)
b/ missing support for tkill syscall. Added to V (now in branch), Wine
fixed to use the better tgkill syscall (0.9.8)
c/ some missing instrumentation of Wine (regarding stack manipulation).
Wine fixed (0.9.8)
d/ possibility to change EIP in signal handler. Added to V (now in
branch, for x86).
e/ trapno is not passed in signal handlers. A hacky patch proposed, and
rightfully rejected. Solution in sight (Tom Hughes), not yet in branch.
f/ missing instruction emulation in VEX (x86, and likely amd 64). Wine
needs:
push/pop [ds,es,ss]
iret (on 32bit intercall, cs not changed)(*)
int 3
cli/sti
(*) actually, Wine would require much more for 16bit emulation, but
I don't think it's reasonable, nor a short term goal, to use V &
Wine for 16bit code.
The push/pop code was easy to fix (it's already written). However
iret will be a bit trickier (I have a dirty hack for iret and int 3,
but likely Julian would rather do it himself ;-). We can try to get
rid of the cli/sti pair.
g/ missing stack backtrace information
As already explained, the first thread of a process is handled
as follows: it starts using the stack created from the process
creation (from Unix). As the process may require a larger stack
(from the Windows definition of the PE header), the Wine loader
always create a second stack at the loader startup, and switch
execution to that second stack when calling the PE module entry
point.
The outcome of this, from a V point of view, is that we get two
stacks (values are important):
- first stack at 0xBE??????
- second stack at 0x20?????? (ie below the first one).
The second stack is declared to V by Wine.
When V needs to print a backtrace (for any issue), in
get_StackTrace2 there's a test:
if (fp_min + VG_(clo_max_stackframe) <= fp_max) {
Here fp_min gets its value from the second stack (in the
0x20?????? area, and fp_max in the 0xbe?????? area). The outcome
is that no backtrace is generated :-/. Trying to remove the test
(or increase the max_stackframe value) provides some other
issues as not all the area in the 0x20????? - 0xbe000000 is
mapped, hence having a some crashes.
This one is a bit more hairy to fix. I have a patch that mixes
the max_stackframe test, with some extra test about the stacks
that are known by V (and checking that info for the backtrace
really points to the stack). But since V doesn't make use of
this information, it must be for good reasons.
The net result of this is:
- because of g/, we cannot get a full backtrace of an issue found by V.
Currently, we disabled the offending test in get_StackTrace2 pointed out
in g. With the listed side effects (crashes), and we'd like to have
something working out of the box (from the V branches)
- because of e/ and f/, we cannot use Wine and V on programs triggering
exceptions (the missing parts in e/ and f/ are only used in those
occasions).
I'd really like to see e/, f/ and g/ fixed. Let me know if you need some
help.
The good side of the story:
- we ran the regression tests (from the Wine regression test suite) on 5
DLLs under V, and fixed something like 15 potential issues and bugs
(even if some tests don't work under V yet)
- that's worth going further and run the full Wine regression tests under V.
A+
--
Eric Pouech
|
|
From: Stephen M.
|
>>>>> "NN" == Nicholas Nethercote <nj...@cs...> writes: NN> On Fri, 24 Feb 2006, Stephen McCamant wrote: SMcC> One potentially significant difference is that we still link SMcC> with glibc (I get the impression that's discouraged, but we're SMcC> loathe to give up fprintf() and friends), now statically. NN> What does fprintf() do that you need that VG_(printf)() doesn't? The usual, printing to file descriptors other than 2. So, you might ask, what does fprintf() do that VG_(sprintf)() and VG_(write)() don't? Buffering, though we haven't actually measured the speed difference. In general, there's nothing we're currently getting from glibc that couldn't be reimplemented on top of the primitives Valgrind provides, and we'd like to go in that direction eventually, but we're waiting for a reason that makes it worth the effort, and we haven't found one yet. In fact, I just checked now the list of symbols we're using from glibc (shown below). It's even longer than I'd remembered, and it includes a number of functions that have perfectly good VG_()() versions. (Many of them probably come from the readelf code that we've assimilated without much editing.) _IO_putc __assert_fail __ctype_b_loc __errno_location _exit abort atoi calloc close dup dup2 execv fclose fcntl fdopen fflush fgets fopen fopen64 fork fprintf fputc fputs fread free fscanf fseek ftell fwrite getenv getopt_long gmtime mkdir mkfifo open64 optarg pipe printf putchar puts remove setvbuf sprintf stat stderr stdout strerror strncpy strstr strtok strtoul tfind tsearch vfprintf waitpid -- Stephen |
|
From: <sv...@va...> - 2006-02-25 04:50:36
|
Author: njn
Date: 2006-02-25 04:50:26 +0000 (Sat, 25 Feb 2006)
New Revision: 5699
Log:
Previously in STOREV1 if the 4-byte word that encompassed the 1 byte bein=
g=20
written wasn't entirely addressible, we'd fall back to the slow case. No=
w,
if the 4-byte addressability test fails I check for 1-byte addressability=
.
This avoids the slow case a lot in some cases. It speeds up perf/bz2 fro=
m=20
21.5s to 19.5s on one machine, and the SPEC bzip2 benchmark with "test"=20
input goes from 208 seconds to 138 seconds.
Modified:
branches/COMPVBITS/memcheck/mc_main.c
Modified: branches/COMPVBITS/memcheck/mc_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/mc_main.c 2006-02-24 10:36:54 UTC (rev 56=
98)
+++ branches/COMPVBITS/memcheck/mc_main.c 2006-02-25 04:50:26 UTC (rev 56=
99)
@@ -3171,9 +3171,13 @@
sm =3D get_secmap_readable_low(a);
sm_off =3D SM_OFF(a);
vabits8 =3D sm->vabits8[sm_off];
- if (EXPECTED_TAKEN( !is_distinguished_sm(sm) &&=20
- (VA_BITS8_READABLE =3D=3D vabits8 ||
- VA_BITS8_WRITABLE =3D=3D vabits8) ))
+ if (EXPECTED_TAKEN
+ ( !is_distinguished_sm(sm) &&
+ ( (VA_BITS8_READABLE =3D=3D vabits8 || VA_BITS8_WRITABLE =3D=3D=
vabits8)
+ || (VA_BITS2_NOACCESS !=3D extract_vabits2_from_vabits8(a, vab=
its8))
+ )
+ )
+ )
{
/* Handle common case quickly: a is mapped, the entire word32 it
lives in is addressible. */
|
|
From: <js...@ac...> - 2006-02-25 04:11:21
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-25 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Feb 25 03:52:53 2006 --- new.short Sat Feb 25 04:10:11 2006 *************** *** 10,12 **** ! == 223 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) --- 10,12 ---- ! == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) *************** *** 15,17 **** memcheck/tests/x86/scalar_supp (stderr) - none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) --- 15,16 ---- |
|
From: Tom H. <to...@co...> - 2006-02-25 03:43:45
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-25 03:30:06 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 == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:31:26
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-25 03:15:03 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 == 224 tests, 21 stderr failures, 1 stdout failure ================= 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-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (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/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:30:29
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-25 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 == 245 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:25:13
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-25 03:10:11 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:22:13
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-25 03:05:12 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Nicholas N. <nj...@cs...> - 2006-02-25 01:45:48
|
On Fri, 24 Feb 2006, Stephen McCamant wrote: > One potentially significant difference is that we still > link with glibc (I get the impression that's discouraged, but we're > loathe to give up fprintf() and friends), now statically. What does fprintf() do that you need that VG_(printf)() doesn't? I have no idea about the MXCSR question... Nick |
|
From: Geoff S. <gs...@us...> - 2006-02-25 01:03:11
|
I took a look at the valgrind --tool=lackey --trace-mem=yes output. With the trace-mem implementation, adding instruction tracing here seems to make sense. So I'd like to propose two alternatives. Alternative A. A separate itrace tool, as I proposed in http://sourceforge.net/mailarchive/message.php?msg_id=14760370 Alternative B. Dovetailing itrace into lackey as follows. The biggest impact to lackey would be adding the option --trace-instr=, and changing the output format to the record-oriented one I proposed before. This would reduce volume of output while keeping postprocessing easy. I would change chapter 9 of the user manual as follows: ------------------------------------------------------ 9. LACKEY, a very simple profiler and trace tool To use this tool, specify --tool=lackey on the Valgrind command line. Lackey is a simple Valgrind tool that provides a simple trace capability and some basic program measurement. It adds quite a lot of simple instrumentation to the program's code. It is primarily intended to be of use as an example tool. _Tracing Output_ Tracing output (if specified) is generated during program execution. Lackey can provide a trace of each instruction that is executed in your program, or a trace of memory accesses, or both by showing memory accesses associated with each instruction. _Profiling Output_ Lackey reports profiling information at the conclusion of program execution. The report includes: o The number of calls to the function specified by --fnname switch o The number of conditional branches encountered and the number and proportion of those taken. o Statistics about the amount of work done during the execution of the client program: o The number of basic blocks entered and completed by the program. Note that due to optimisations done by the JIT, this is not really an accurate value. o The number of guest (x86, amd64, ppc, etc.) instructions and IR statements executed. IR is Valgrind's RISC-like intermediate representation via which all instrumentation is done. o Ratios between some of these counts. 9.2 Command-line options specific to lackey --fnname=<name> Specifies the function to profile (and trace). The default is _dl_runtime_resolve(), the function in glibc's dynamic linker that resolves function references to shared objects. --trace-extent=all,function,calltree Specifies whether to trace the entire program, the instructions in the function specified by --fnname, or all instructions from entry into the function until the function returns. The default is calltree. --trace-instrs=yes Enables tracing of instructions. --trace-mem=yes Enables tracing of memory accesses. --detailed-counts=yes Profiling output includes a table with counts of loads, stores and ALU operations for various types of operands. The types are identified by their IR name ("I1" ... "I128", "F32", "F64", and "V128"). Also prints the exit code of the client program. 9.3 Trace Output The trace output consists of an ASCII-formatted trace of the instructions executed. The format is very simple to facilitate post-processing. The first character of each line ("record") indicates what kind of data is included in the line. Trace output is provided only if enabled. --trace-instr enables H, I, J, and G records. --trace-mem=yes enables H, R, and W records. Example ("..." indicates skipped records) ==14778== valgrind-itrace, Instruction and memory tracer. ==14778== Copyright (C) 2005, and GNU GPL'd. ==14778== Using LibVEX rev 1471, a library for dynamic binary translation. ==14778== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==14778== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==14778== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==14778== For more details, rerun with: -v ==14778== H valgrind-itrace J 00244C67 55 ; dl_start ... J 08048394 55 ; main W BE8619A8 BE861A08 I 89E5 I 83EC08 I 83E4F0 I B800000000 I 83C00F I 83C00F I C1E804 I C1E004 I 29C4 I E8C7FFFFFF W BE86198C 080483B5 G J 0804837C 55 ; print W BE861988 BE8619A8 I 89E5 ... Record definitions H whatever ... Indicates the start of the trace, possibly with additional data in no specific format. J aaaa xxxx [; symbol] Instruction-with-address record. aaaa is the address of the instruction, xxxx is a byte dump of the instruction itself. All values are in hex. Optionally, a symbol name associated with the address may be provided. Note that "J" does not imply that a branch occurred, it merely indicates that the record includes the address of the instruction executed. I xxxx Instruction record for an instruction that immediately follows the previous instruction. The address can be determined from the length of the preceding instruction. G Indicates a gap in the trace. This will happen, for instance, when valgrind simulates a system call via an int 80 (on x86) or sc (on ppc) instruction, or when a branch occurs to code not being traced. R aaaaaaaa rrrr W aaaaaaaa wwwwwwww Indicates that the previous instruction caused a read of the bytes rrrr at the address, or a write of bytes wwww. The length of the read or write is indicated by the number of bytes shown. R and W records occur in logical order; for instance, an increment-memory instruction will show the read followed by the write. 9.4 Limitations Lackey runs quite slowly, especially when --detailed-counts=yes is specified. It could be made to run a lot faster by doing a slightly more sophisticated job of the instrumentation, but that would undermine its role as a simple example tool. Hence we have chosen not to do so. Memory tracing cannot catch every load and store access. See section 3.3.7 of Nicholas Nethercote's PhD dissertation "Dynamic Binary Analysis and Instrumentation", 2004, for details about the few loads and stores that is misses, and other caveats about the accuracy of the memory trace. When --trace-extent=calltree is specified, the tracing will stop only when the function returns to its caller. Tracing will not stop if the function does not return to its caller. Some examples of this are raising C++ or Ada exceptions and longjump. Also, signals and task switching may cause unexpected code to be included in the trace. |