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
(44) |
2
(9) |
3
(30) |
4
(28) |
5
(42) |
6
(14) |
7
(10) |
|
8
(7) |
9
(8) |
10
(6) |
11
(15) |
12
(13) |
13
(14) |
14
(23) |
|
15
(17) |
16
(10) |
17
(82) |
18
(14) |
19
(21) |
20
(14) |
21
(21) |
|
22
(7) |
23
(13) |
24
(16) |
25
(11) |
26
(11) |
27
(6) |
28
(7) |
|
29
(8) |
30
(13) |
31
(8) |
|
|
|
|
|
From: <sv...@va...> - 2006-10-21 23:19:57
|
Author: njn Date: 2006-10-22 00:19:52 +0100 (Sun, 22 Oct 2006) New Revision: 6337 Log: Update for recent removal of Cachegrind tech docs. MERGED FROM TRUNK Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/Makefile.am Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/Makefile.am =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/VALGRIND_3_2_BRANCH/cachegrind/docs/Makefile.am 2006-10-21 2= 3:18:57 UTC (rev 6336) +++ branches/VALGRIND_3_2_BRANCH/cachegrind/docs/Makefile.am 2006-10-21 2= 3:19:52 UTC (rev 6337) @@ -1 +1 @@ -EXTRA_DIST =3D cg-manual.xml cg-tech-docs.xml=20 +EXTRA_DIST =3D cg-manual.xml |
|
From: <sv...@va...> - 2006-10-21 23:19:01
|
Author: njn Date: 2006-10-22 00:18:57 +0100 (Sun, 22 Oct 2006) New Revision: 6336 Log: Update for recent removal of Cachegrind tech docs. Modified: trunk/cachegrind/docs/Makefile.am Modified: trunk/cachegrind/docs/Makefile.am =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 --- trunk/cachegrind/docs/Makefile.am 2006-10-21 23:02:13 UTC (rev 6335) +++ trunk/cachegrind/docs/Makefile.am 2006-10-21 23:18:57 UTC (rev 6336) @@ -1 +1 @@ -EXTRA_DIST =3D cg-manual.xml cg-tech-docs.xml=20 +EXTRA_DIST =3D cg-manual.xml |
|
From: <sv...@va...> - 2006-10-21 23:02:23
|
Author: njn Date: 2006-10-22 00:02:13 +0100 (Sun, 22 Oct 2006) New Revision: 6335 Log: Link to dissertation with a proper link. MERGED FROM TRUNK Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml branches/VALGRIND_3_2_BRANCH/docs/xml/vg-entities.xml Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml =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/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml 2006-10-21= 23:00:59 UTC (rev 6334) +++ branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml 2006-10-21= 23:02:13 UTC (rev 6335) @@ -1023,7 +1023,8 @@ <title>How Cachegrind works</title> <para>The best reference for understanding how Cachegrind works is chapt= er 3 of "Dynamic Binary Analysis and Instrumentation", by Nicholas Nethercote. = It -is available on the publications page of the Valgrind website.</para> +is available on the <ulink url=3D"&vg-pubs;">Valgrind publications +page</ulink>.</para> </sect2> =20 <sect2> Modified: branches/VALGRIND_3_2_BRANCH/docs/xml/vg-entities.xml =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/VALGRIND_3_2_BRANCH/docs/xml/vg-entities.xml 2006-10-21 23:0= 0:59 UTC (rev 6334) +++ branches/VALGRIND_3_2_BRANCH/docs/xml/vg-entities.xml 2006-10-21 23:0= 2:13 UTC (rev 6335) @@ -7,8 +7,8 @@ =20 <!-- valgrind release + version stuff --> <!ENTITY rel-type "Release"> -<!ENTITY rel-version "3.2.1"> -<!ENTITY rel-date "16 September 2006"> +<!ENTITY rel-version "3.2.0"> +<!ENTITY rel-date "7 June 2006"> =20 <!-- where the docs are installed --> <!ENTITY vg-doc-path "/usr/share/doc/valgrind/html/index.html"> @@ -18,6 +18,7 @@ <!-- a real pain tracking the links down in the docs --> <!ENTITY vg-developers "http://www.valgrind.org/info/developers.html"> <!ENTITY vg-svn-repo "http://www.valgrind.org/downloads/repository.htm= l"> +<!ENTITY vg-pubs "http://www.valgrind.org/docs/pubs.html"> <!ENTITY vg-bookset "http://www.valgrind.org/docs/manual/index.html"> <!ENTITY vg-dist-docs "http://www.valgrind.org/docs/manual/dist.html"> <!ENTITY vg-commentary "http://www.valgrind.org/docs/manual/manual-core.= html#manual-core.comment"> |
|
From: <sv...@va...> - 2006-10-21 23:01:03
|
Author: njn Date: 2006-10-22 00:00:59 +0100 (Sun, 22 Oct 2006) New Revision: 6334 Log: Link to dissertation with a proper link. Modified: trunk/cachegrind/docs/cg-manual.xml trunk/docs/xml/vg-entities.xml Modified: trunk/cachegrind/docs/cg-manual.xml =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 --- trunk/cachegrind/docs/cg-manual.xml 2006-10-21 22:25:56 UTC (rev 6333= ) +++ trunk/cachegrind/docs/cg-manual.xml 2006-10-21 23:00:59 UTC (rev 6334= ) @@ -1023,7 +1023,8 @@ <title>How Cachegrind works</title> <para>The best reference for understanding how Cachegrind works is chapt= er 3 of "Dynamic Binary Analysis and Instrumentation", by Nicholas Nethercote. = It -is available on the publications page of the Valgrind website.</para> +is available on the <ulink url=3D"&vg-pubs;">Valgrind publications +page</ulink>.</para> </sect2> =20 <sect2> Modified: trunk/docs/xml/vg-entities.xml =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 --- trunk/docs/xml/vg-entities.xml 2006-10-21 22:25:56 UTC (rev 6333) +++ trunk/docs/xml/vg-entities.xml 2006-10-21 23:00:59 UTC (rev 6334) @@ -18,6 +18,7 @@ <!-- a real pain tracking the links down in the docs --> <!ENTITY vg-developers "http://www.valgrind.org/info/developers.html"> <!ENTITY vg-svn-repo "http://www.valgrind.org/downloads/repository.htm= l"> +<!ENTITY vg-pubs "http://www.valgrind.org/docs/pubs.html"> <!ENTITY vg-bookset "http://www.valgrind.org/docs/manual/index.html"> <!ENTITY vg-dist-docs "http://www.valgrind.org/docs/manual/dist.html"> <!ENTITY vg-commentary "http://www.valgrind.org/docs/manual/manual-core.= html#manual-core.comment"> |
|
From: <sv...@va...> - 2006-10-21 22:26:01
|
Author: njn Date: 2006-10-21 23:25:56 +0100 (Sat, 21 Oct 2006) New Revision: 6333 Log: Removed the file format description from cg_annotate.in, because it's in = the Cachegrind docs. Removed the Cachegrind tech docs, because they're so out of date to be useless. My PhD dissertation gives a much better description of how Cachegrind works. (I mentioned this in the Cachegrind user manual.) The only still-useful part of Cachegrind's tech docs, the output file format description, I moved into the Cachegrind user manual. MERGED FROM TRUNK Removed: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-tech-docs.xml Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml branches/VALGRIND_3_2_BRANCH/docs/xml/tech-docs.xml Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in =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/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in 2006-10-21 22:= 22:59 UTC (rev 6332) +++ branches/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in 2006-10-21 22:= 25:56 UTC (rev 6333) @@ -29,47 +29,8 @@ =20 #-----------------------------------------------------------------------= ----- # The file format is simple, basically printing the cost centre for ever= y -# source line, grouped by files and functions: -#=20 -# file ::=3D desc_line* cmd_line events_line data_line+ summar= y_line -# desc_line ::=3D "desc:" ws? non_nl_string -# cmd_line ::=3D "cmd:" ws? cmd -# events_line ::=3D "events:" ws? (event ws)+ -# data_line ::=3D file_line | fn_line | count_line -# file_line ::=3D "fl=3D" filename -# fn_line ::=3D "fn=3D" fn_name -# count_line ::=3D line_num ws? (count ws)+ -# summary_line ::=3D "summary:" ws? (count ws)+ -# count ::=3D num | "." -#=20 -# where -# 'non_nl_string' is any string not containing a newline. -# 'cmd' is a string holding the command line of the profiled program. -# 'filename' and 'fn_name' are strings. -# 'num' and 'line_num' are decimal integers. -# 'ws' is whitespace. -#=20 -# The contents of the "desc:" lines are printed out at the top -# of the summary. This is a generic way of providing simulation -# specific information, eg. for giving the cache configuration for -# cache simulation. -#=20 -# More than one line of info can be presented for each file/fn/line numb= er. -# In such cases, the counts for the named events will be accumulated. -# -# Counts can be "." to represent zero. This makes the files easier to r= ead. -#=20 -# The number of counts in each 'line' and the 'summary_line' should not = exceed -# the number of events in the 'event_line'. If the number in each 'line= ' is -# less, cg_annotate treats those missing as though they were a "." entry= . -#=20 -# A 'file_line' changes the current file name. A 'fn_line' changes the -# current function name. A 'count_line' contains counts that pertain to= the -# current filename/fn_name. A 'file_line' and a 'fn_line' must appear -# before any 'count_line's to give the context of the first 'count_line'= . -#=20 -# Each 'file_line' will normally be immediately followed by a 'fn_line'. -# But it doesn't have to be. +# source line, grouped by files and functions. The details are in +# Cachegrind's manual. =20 #-----------------------------------------------------------------------= ----- # Performance improvements record, using cachegrind.out for cacheprof, d= oing no Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml =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/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml 2006-10-21= 22:22:59 UTC (rev 6332) +++ branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-manual.xml 2006-10-21= 22:25:56 UTC (rev 6333) @@ -6,12 +6,6 @@ <chapter id=3D"cg-manual" xreflabel=3D"Cachegrind: a cache-miss profiler= "> <title>Cachegrind: a cache profiler</title> =20 -<para>Detailed technical documentation on how Cachegrind works is -available in <xref linkend=3D"cg-tech-docs"/>. If you only want to know -how to <command>use</command> it, this is the page you need to -read.</para> - - <sect1 id=3D"cg-manual.cache" xreflabel=3D"Cache profiling"> <title>Cache profiling</title> =20 @@ -1018,18 +1012,101 @@ =20 </sect2> =20 +</sect1> =20 +<sect1> +<title>Implementation details</title> +This section talks about details you don't need to know about in order t= o +use Cachegrind, but may be of interest to some people. + <sect2> -<title>Todo</title> +<title>How Cachegrind works</title> +<para>The best reference for understanding how Cachegrind works is chapt= er 3 of +"Dynamic Binary Analysis and Instrumentation", by Nicholas Nethercote. = It +is available on the publications page of the Valgrind website.</para> +</sect2> =20 +<sect2> +<title>Cachegrind output file format</title> +<para>The file format is fairly straightforward, basically giving the +cost centre for every line, grouped by files and +functions. Total counts (eg. total cache accesses, total L1 +misses) are calculated when traversing this structure rather than +during execution, to save time; the cache simulation functions +are called so often that even one or two extra adds can make a +sizeable difference.</para> + +<para>The file format:</para> +<programlisting><![CDATA[ +file ::=3D desc_line* cmd_line events_line data_line+ summary_li= ne +desc_line ::=3D "desc:" ws? non_nl_string +cmd_line ::=3D "cmd:" ws? cmd +events_line ::=3D "events:" ws? (event ws)+ +data_line ::=3D file_line | fn_line | count_line +file_line ::=3D "fl=3D" filename +fn_line ::=3D "fn=3D" fn_name +count_line ::=3D line_num ws? (count ws)+ +summary_line ::=3D "summary:" ws? (count ws)+ +count ::=3D num | "."]]></programlisting> + +<para>Where:</para> <itemizedlist> <listitem> - <para>Program start-up/shut-down calls a lot of functions - that aren't interesting and just complicate the output. - Would be nice to exclude these somehow.</para> + <para><computeroutput>non_nl_string</computeroutput> is any + string not containing a newline.</para> </listitem> -</itemizedlist>=20 + <listitem> + <para><computeroutput>cmd</computeroutput> is a string holding the + command line of the profiled program.</para> + </listitem> + <listitem> + <para><computeroutput>filename</computeroutput> and + <computeroutput>fn_name</computeroutput> are strings.</para> + </listitem> + <listitem> + <para><computeroutput>num</computeroutput> and + <computeroutput>line_num</computeroutput> are decimal + numbers.</para> + </listitem> + <listitem> + <para><computeroutput>ws</computeroutput> is whitespace.</para> + </listitem> +</itemizedlist> =20 +<para>The contents of the "desc:" lines are printed out at the top +of the summary. This is a generic way of providing simulation +specific information, eg. for giving the cache configuration for +cache simulation.</para> + +<para>More than one line of info can be presented for each file/fn/line = number. +In such cases, the counts for the named events will be accumulated.</par= a> + +<para>Counts can be "." to represent zero. This makes the files easier = to +read.</para> + +<para>The number of counts in each +<computeroutput>line</computeroutput> and the +<computeroutput>summary_line</computeroutput> should not exceed +the number of events in the +<computeroutput>event_line</computeroutput>. If the number in +each <computeroutput>line</computeroutput> is less, cg_annotate +treats those missing as though they were a "." entry.</para> + +<para>A <computeroutput>file_line</computeroutput> changes the +current file name. A <computeroutput>fn_line</computeroutput> +changes the current function name. A +<computeroutput>count_line</computeroutput> contains counts that +pertain to the current filename/fn_name. A "fn=3D" +<computeroutput>file_line</computeroutput> and a +<computeroutput>fn_line</computeroutput> must appear before any +<computeroutput>count_line</computeroutput>s to give the context +of the first <computeroutput>count_line</computeroutput>s.</para> + +<para>Each <computeroutput>file_line</computeroutput> will normally be +immediately followed by a <computeroutput>fn_line</computeroutput>. But= it +doesn't have to be.</para> + + </sect2> =20 </sect1> Deleted: branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-tech-docs.xml =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/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-tech-docs.xml 2006-10= -21 22:22:59 UTC (rev 6332) +++ branches/VALGRIND_3_2_BRANCH/cachegrind/docs/cg-tech-docs.xml 2006-10= -21 22:25:56 UTC (rev 6333) @@ -1,563 +0,0 @@ -<?xml version=3D"1.0"?> <!-- -*- sgml -*- --> -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<chapter id=3D"cg-tech-docs" xreflabel=3D"How Cachegrind works"> - -<title>How Cachegrind works</title> - -<sect1 id=3D"cg-tech-docs.profiling" xreflabel=3D"Cache profiling"> -<title>Cache profiling</title> - -<para>[Note: this document is now very old, and a lot of its contents ar= e out -of date, and misleading.]</para> - -<para>Valgrind is a very nice platform for doing cache profiling -and other kinds of simulation, because it converts horrible x86 -instructions into nice clean RISC-like UCode. For example, for -cache profiling we are interested in instructions that read and -write memory; in UCode there are only four instructions that do -this: <computeroutput>LOAD</computeroutput>, -<computeroutput>STORE</computeroutput>, -<computeroutput>FPU_R</computeroutput> and -<computeroutput>FPU_W</computeroutput>. By contrast, because of -the x86 addressing modes, almost every instruction can read or -write memory.</para> - -<para>Most of the cache profiling machinery is in the file -<filename>vg_cachesim.c</filename>.</para> - -<para>These notes are a somewhat haphazard guide to how -Valgrind's cache profiling works.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.costcentres" xreflabel=3D"Cost centres"> -<title>Cost centres</title> - -<para>Valgrind gathers cache profiling about every instruction -executed, individually. Each instruction has a <command>cost -centre</command> associated with it. There are two kinds of cost -centre: one for instructions that don't reference memory -(<computeroutput>iCC</computeroutput>), and one for instructions -that do (<computeroutput>idCC</computeroutput>):</para> - -<programlisting><![CDATA[ -typedef struct _CC { - ULong a; - ULong m1; - ULong m2; -} CC; - -typedef struct _iCC { - /* word 1 */ - UChar tag; - UChar instr_size; - - /* words 2+ */ - Addr instr_addr; - CC I; -} iCC; - =20 -typedef struct _idCC { - /* word 1 */ - UChar tag; - UChar instr_size; - UChar data_size; - - /* words 2+ */ - Addr instr_addr; - CC I;=20 - CC D;=20 -} idCC; ]]></programlisting> - -<para>Each <computeroutput>CC</computeroutput> has three fields -<computeroutput>a</computeroutput>, -<computeroutput>m1</computeroutput>, -<computeroutput>m2</computeroutput> for recording references, -level 1 misses and level 2 misses. Each of these is a 64-bit -<computeroutput>ULong</computeroutput> -- the numbers can get -very large, ie. greater than 4.2 billion allowed by a 32-bit -unsigned int.</para> - -<para>A <computeroutput>iCC</computeroutput> has one -<computeroutput>CC</computeroutput> for instruction cache -accesses. A <computeroutput>idCC</computeroutput> has two, one -for instruction cache accesses, and one for data cache -accesses.</para> - -<para>The <computeroutput>iCC</computeroutput> and -<computeroutput>dCC</computeroutput> structs also store -unchanging information about the instruction:</para> -<itemizedlist> - <listitem> - <para>An instruction-type identification tag (explained - below)</para> - </listitem> - <listitem> - <para>Instruction size</para> - </listitem> - <listitem> - <para>Data reference size - (<computeroutput>idCC</computeroutput> only)</para> - </listitem> - <listitem> - <para>Instruction address</para> - </listitem> -</itemizedlist> - -<para>Note that data address is not one of the fields for -<computeroutput>idCC</computeroutput>. This is because for many -memory-referencing instructions the data address can change each -time it's executed (eg. if it uses register-offset addressing). -We have to give this item to the cache simulation in a different -way (see Instrumentation section below). Some memory-referencing -instructions do always reference the same address, but we don't -try to treat them specialy in order to keep things simple.</para> - -<para>Also note that there is only room for recording info about -one data cache access in an -<computeroutput>idCC</computeroutput>. So what about -instructions that do a read then a write, such as:</para> -<programlisting><![CDATA[ -inc %(esi)]]></programlisting> - -<para>In a write-allocate cache, as simulated by Valgrind, the -write cannot miss, since it immediately follows the read which -will drag the block into the cache if it's not already there. So -the write access isn't really interesting, and Valgrind doesn't -record it. This means that Valgrind doesn't measure memory -references, but rather memory references that could miss in the -cache. This behaviour is the same as that used by the AMD Athlon -hardware counters. It also has the benefit of simplifying the -implementation -- instructions that read and write memory can be -treated like instructions that read memory.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.ccstore" xreflabel=3D"Storing cost-centres"> -<title>Storing cost-centres</title> - -<para>Cost centres are stored in a way that makes them very cheap -to lookup, which is important since one is looked up for every -original x86 instruction executed.</para> - -<para>Valgrind does JIT translations at the basic block level, -and cost centres are also setup and stored at the basic block -level. By doing things carefully, we store all the cost centres -for a basic block in a contiguous array, and lookup comes almost -for free.</para> - -<para>Consider this part of a basic block (for exposition -purposes, pretend it's an entire basic block):</para> -<programlisting><![CDATA[ -movl $0x0,%eax -movl $0x99, -4(%ebp)]]></programlisting> - -<para>The translation to UCode looks like this:</para> -<programlisting><![CDATA[ -MOVL $0x0, t20 -PUTL t20, %EAX -INCEIPo $5 - -LEA1L -4(t4), t14 -MOVL $0x99, t18 -STL t18, (t14) -INCEIPo $7]]></programlisting> - -<para>The first step is to allocate the cost centres. This -requires a preliminary pass to count how many x86 instructions -were in the basic block, and their types (and thus sizes). UCode -translations for single x86 instructions are delimited by the -<computeroutput>INCEIPo</computeroutput> instruction, the -argument of which gives the byte size of the instruction (note -that lazy INCEIP updating is turned off to allow this).</para> - -<para>We can tell if an x86 instruction references memory by -looking for <computeroutput>LDL</computeroutput> and -<computeroutput>STL</computeroutput> UCode instructions, and thus -what kind of cost centre is required. From this we can determine -how many cost centres we need for the basic block, and their -sizes. We can then allocate them in a single array.</para> - -<para>Consider the example code above. After the preliminary -pass, we know we need two cost centres, one -<computeroutput>iCC</computeroutput> and one -<computeroutput>dCC</computeroutput>. So we allocate an array to -store these which looks like this:</para> - -<programlisting><![CDATA[ -|(uninit)| tag (1 byte) -|(uninit)| instr_size (1 bytes) -|(uninit)| (padding) (2 bytes) -|(uninit)| instr_addr (4 bytes) -|(uninit)| I.a (8 bytes) -|(uninit)| I.m1 (8 bytes) -|(uninit)| I.m2 (8 bytes) - -|(uninit)| tag (1 byte) -|(uninit)| instr_size (1 byte) -|(uninit)| data_size (1 byte) -|(uninit)| (padding) (1 byte) -|(uninit)| instr_addr (4 bytes) -|(uninit)| I.a (8 bytes) -|(uninit)| I.m1 (8 bytes) -|(uninit)| I.m2 (8 bytes) -|(uninit)| D.a (8 bytes) -|(uninit)| D.m1 (8 bytes) -|(uninit)| D.m2 (8 bytes)]]></programlisting> - -<para>(We can see now why we need tags to distinguish between the -two types of cost centres.)</para> - -<para>We also record the size of the array. We look up the debug -info of the first instruction in the basic block, and then stick -the array into a table indexed by filename and function name. -This makes it easy to dump the information quickly to file at the -end.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.instrum" xreflabel=3D"Instrumentation"> -<title>Instrumentation</title> - -<para>The instrumentation pass has two main jobs:</para> - -<orderedlist> - <listitem> - <para>Fill in the gaps in the allocated cost centres.</para> - </listitem> - <listitem> - <para>Add UCode to call the cache simulator for each - instruction.</para> - </listitem> -</orderedlist> - -<para>The instrumentation pass steps through the UCode and the -cost centres in tandem. As each original x86 instruction's UCode -is processed, the appropriate gaps in the instructions cost -centre are filled in, for example:</para> - -<programlisting><![CDATA[ -|INSTR_CC| tag (1 byte) -|5 | instr_size (1 bytes) -|(uninit)| (padding) (2 bytes) -|i_addr1 | instr_addr (4 bytes) -|0 | I.a (8 bytes) -|0 | I.m1 (8 bytes) -|0 | I.m2 (8 bytes) - -|WRITE_CC| tag (1 byte) -|7 | instr_size (1 byte) -|4 | data_size (1 byte) -|(uninit)| (padding) (1 byte) -|i_addr2 | instr_addr (4 bytes) -|0 | I.a (8 bytes) -|0 | I.m1 (8 bytes) -|0 | I.m2 (8 bytes) -|0 | D.a (8 bytes) -|0 | D.m1 (8 bytes) -|0 | D.m2 (8 bytes)]]></programlisting> - -<para>(Note that this step is not performed if a basic block is -re-translated; see <xref linkend=3D"cg-tech-docs.retranslations"/> for -more information.)</para> - -<para>GCC inserts padding before the -<computeroutput>instr_size</computeroutput> field so that it is -word aligned.</para> - -<para>The instrumentation added to call the cache simulation -function looks like this (instrumentation is indented to -distinguish it from the original UCode):</para> - -<programlisting><![CDATA[ -MOVL $0x0, t20 -PUTL t20, %EAX - PUSHL %eax - PUSHL %ecx - PUSHL %edx - MOVL $0x4091F8A4, t46 # address of 1st CC - PUSHL t46 - CALLMo $0x12 # second cachesim function - CLEARo $0x4 - POPL %edx - POPL %ecx - POPL %eax -INCEIPo $5 - -LEA1L -4(t4), t14 -MOVL $0x99, t18 - MOVL t14, t42 -STL t18, (t14) - PUSHL %eax - PUSHL %ecx - PUSHL %edx - PUSHL t42 - MOVL $0x4091F8C4, t44 # address of 2nd CC - PUSHL t44 - CALLMo $0x13 # second cachesim function - CLEARo $0x8 - POPL %edx - POPL %ecx - POPL %eax -INCEIPo $7]]></programlisting> - -<para>Consider the first instruction's UCode. Each call is -surrounded by three <computeroutput>PUSHL</computeroutput> and -<computeroutput>POPL</computeroutput> instructions to save and -restore the caller-save registers. Then the address of the -instruction's cost centre is pushed onto the stack, to be the -first argument to the cache simulation function. The address is -known at this point because we are doing a simultaneous pass -through the cost centre array. This means the cost centre lookup -for each instruction is almost free (just the cost of pushing an -argument for a function call). Then the call to the cache -simulation function for non-memory-reference instructions is made -(note that the <computeroutput>CALLMo</computeroutput> -UInstruction takes an offset into a table of predefined -functions; it is not an absolute address), and the single -argument is <computeroutput>CLEAR</computeroutput>ed from the -stack.</para> - -<para>The second instruction's UCode is similar. The only -difference is that, as mentioned before, we have to pass the -address of the data item referenced to the cache simulation -function too. This explains the <computeroutput>MOVL t14, -t42</computeroutput> and <computeroutput>PUSHL -t42</computeroutput> UInstructions. (Note that the seemingly -redundant <computeroutput>MOV</computeroutput>ing will probably -be optimised away during register allocation.)</para> - -<para>Note that instead of storing unchanging information about -each instruction (instruction size, data size, etc) in its cost -centre, we could have passed in these arguments to the simulation -function. But this would slow the calls down (two or three extra -arguments pushed onto the stack). Also it would bloat the UCode -instrumentation by amounts similar to the space required for them -in the cost centre; bloated UCode would also fill the translation -cache more quickly, requiring more translations for large -programs and slowing them down more.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.retranslations"=20 - xreflabel=3D"Handling basic block retranslations"> -<title>Handling basic block retranslations</title> - -<para>The above description ignores one complication. Valgrind -has a limited size cache for basic block translations; if it -fills up, old translations are discarded. If a discarded basic -block is executed again, it must be re-translated.</para> - -<para>However, we can't use this approach for profiling -- we -can't throw away cost centres for instructions in the middle of -execution! So when a basic block is translated, we first look -for its cost centre array in the hash table. If there is no cost -centre array, it must be the first translation, so we proceed as -described above. But if there is a cost centre array already, it -must be a retranslation. In this case, we skip the cost centre -allocation and initialisation steps, but still do the UCode -instrumentation step.</para> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.cachesim" xreflabel=3D"The cache simulation"> -<title>The cache simulation</title> - -<para>The cache simulation is fairly straightforward. It just -tracks which memory blocks are in the cache at the moment (it -doesn't track the contents, since that is irrelevant).</para> - -<para>The interface to the simulation is quite clean. The -functions called from the UCode contain calls to the simulation -functions in the files -<filename>vg_cachesim_{I1,D1,L2}.c</filename>; these calls are -inlined so that only one function call is done per simulated x86 -instruction. The file <filename>vg_cachesim.c</filename> simply -<computeroutput>#include</computeroutput>s the three files -containing the simulation, which makes plugging in new cache -simulations is very easy -- you just replace the three files and -recompile.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.output" xreflabel=3D"Output"> -<title>Output</title> - -<para>Output is fairly straightforward, basically printing the -cost centre for every instruction, grouped by files and -functions. Total counts (eg. total cache accesses, total L1 -misses) are calculated when traversing this structure rather than -during execution, to save time; the cache simulation functions -are called so often that even one or two extra adds can make a -sizeable difference.</para> - -<para>Input file has the following format:</para> -<programlisting><![CDATA[ -file ::=3D desc_line* cmd_line events_line data_line+ summary_li= ne -desc_line ::=3D "desc:" ws? non_nl_string -cmd_line ::=3D "cmd:" ws? cmd -events_line ::=3D "events:" ws? (event ws)+ -data_line ::=3D file_line | fn_line | count_line -file_line ::=3D ("fl=3D" | "fi=3D" | "fe=3D") filename -fn_line ::=3D "fn=3D" fn_name -count_line ::=3D line_num ws? (count ws)+ -summary_line ::=3D "summary:" ws? (count ws)+ -count ::=3D num | "."]]></programlisting> - -<para>Where:</para> -<itemizedlist> - <listitem> - <para><computeroutput>non_nl_string</computeroutput> is any - string not containing a newline.</para> - </listitem> - <listitem> - <para><computeroutput>cmd</computeroutput> is a command line - invocation.</para> - </listitem> - <listitem> - <para><computeroutput>filename</computeroutput> and - <computeroutput>fn_name</computeroutput> can be anything.</para> - </listitem> - <listitem> - <para><computeroutput>num</computeroutput> and - <computeroutput>line_num</computeroutput> are decimal - numbers.</para> - </listitem> - <listitem> - <para><computeroutput>ws</computeroutput> is whitespace.</para> - </listitem> - <listitem> - <para><computeroutput>nl</computeroutput> is a newline.</para> - </listitem> - -</itemizedlist> - -<para>The contents of the "desc:" lines is printed out at the top -of the summary. This is a generic way of providing simulation -specific information, eg. for giving the cache configuration for -cache simulation.</para> - -<para>Counts can be "." to represent "N/A", eg. the number of -write misses for an instruction that doesn't write to -memory.</para> - -<para>The number of counts in each -<computeroutput>line</computeroutput> and the -<computeroutput>summary_line</computeroutput> should not exceed -the number of events in the -<computeroutput>event_line</computeroutput>. If the number in -each <computeroutput>line</computeroutput> is less, cg_annotate -treats those missing as though they were a "." entry.</para> - -<para>A <computeroutput>file_line</computeroutput> changes the -current file name. A <computeroutput>fn_line</computeroutput> -changes the current function name. A -<computeroutput>count_line</computeroutput> contains counts that -pertain to the current filename/fn_name. A "fn=3D" -<computeroutput>file_line</computeroutput> and a -<computeroutput>fn_line</computeroutput> must appear before any -<computeroutput>count_line</computeroutput>s to give the context -of the first <computeroutput>count_line</computeroutput>s.</para> - -<para>Each <computeroutput>file_line</computeroutput> should be -immediately followed by a -<computeroutput>fn_line</computeroutput>. "fi=3D" -<computeroutput>file_lines</computeroutput> are used to switch -filenames for inlined functions; "fe=3D" -<computeroutput>file_lines</computeroutput> are similar, but are -put at the end of a basic block in which the file name hasn't -been switched back to the original file name. (fi and fe lines -behave the same, they are only distinguished to help -debugging.)</para> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.summary"=20 - xreflabel=3D"Summary of performance features"> -<title>Summary of performance features</title> - -<para>Quite a lot of work has gone into making the profiling as -fast as possible. This is a summary of the important -features:</para> - -<itemizedlist> - - <listitem> - <para>The basic block-level cost centre storage allows almost - free cost centre lookup.</para> - </listitem> - =20 - <listitem> - <para>Only one function call is made per instruction - simulated; even this accounts for a sizeable percentage of - execution time, but it seems unavoidable if we want - flexibility in the cache simulator.</para> - </listitem> - - <listitem> - <para>Unchanging information about an instruction is stored - in its cost centre, avoiding unnecessary argument pushing, - and minimising UCode instrumentation bloat.</para> - </listitem> - - <listitem> - <para>Summary counts are calculated at the end, rather than - during execution.</para> - </listitem> - - <listitem> - <para>The <computeroutput>cachegrind.out</computeroutput> - output files can contain huge amounts of information; file - format was carefully chosen to minimise file sizes.</para> - </listitem> - -</itemizedlist> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.annotate" xreflabel=3D"Annotation"> -<title>Annotation</title> - -<para>Annotation is done by cg_annotate. It is a fairly -straightforward Perl script that slurps up all the cost centres, -and then runs through all the chosen source files, printing out -cost centres with them. It too has been carefully optimised.</para> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.extensions" xreflabel=3D"Similar work, extensi= ons"> -<title>Similar work, extensions</title> - -<para>It would be relatively straightforward to do other -simulations and obtain line-by-line information about interesting -events. A good example would be branch prediction -- all -branches could be instrumented to interact with a branch -prediction simulator, using very similar techniques to those -described above.</para> - -<para>In particular, cg_annotate would not need to change -- the -file format is such that it is not specific to the cache -simulation, but could be used for any kind of line-by-line -information. The only part of cg_annotate that is specific to -the cache simulation is the name of the input file -(<computeroutput>cachegrind.out</computeroutput>), although it -would be very simple to add an option to control this.</para> - -</sect1> - -</chapter> Modified: branches/VALGRIND_3_2_BRANCH/docs/xml/tech-docs.xml =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/VALGRIND_3_2_BRANCH/docs/xml/tech-docs.xml 2006-10-21 22:22:= 59 UTC (rev 6332) +++ branches/VALGRIND_3_2_BRANCH/docs/xml/tech-docs.xml 2006-10-21 22:25:= 56 UTC (rev 6333) @@ -19,8 +19,6 @@ =20 <xi:include href=3D"../../memcheck/docs/mc-tech-docs.xml" parse=3D"xml= " =20 xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> - <xi:include href=3D"../../cachegrind/docs/cg-tech-docs.xml" parse=3D"x= ml" =20 - xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> <xi:include href=3D"../../callgrind/docs/cl-format.xml" parse=3D"xml" = =20 xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> <xi:include href=3D"writing-tools.xml" parse=3D"xml" =20 |
|
From: <sv...@va...> - 2006-10-21 22:23:05
|
Author: njn Date: 2006-10-21 23:22:59 +0100 (Sat, 21 Oct 2006) New Revision: 6332 Log: Removed the file format description from cg_annotate.in, because it's in = the Cachegrind docs. Removed the Cachegrind tech docs, because they're so out of date to be useless. My PhD dissertation gives a much better description of how Cachegrind works. (I mentioned this in the Cachegrind user manual.) The only still-useful part of Cachegrind's tech docs, the output file format description, I moved into the Cachegrind user manual. Removed: trunk/cachegrind/docs/cg-tech-docs.xml Modified: trunk/cachegrind/cg_annotate.in trunk/cachegrind/docs/cg-manual.xml trunk/docs/xml/tech-docs.xml Modified: trunk/cachegrind/cg_annotate.in =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 --- trunk/cachegrind/cg_annotate.in 2006-10-21 18:25:12 UTC (rev 6331) +++ trunk/cachegrind/cg_annotate.in 2006-10-21 22:22:59 UTC (rev 6332) @@ -29,47 +29,8 @@ =20 #-----------------------------------------------------------------------= ----- # The file format is simple, basically printing the cost centre for ever= y -# source line, grouped by files and functions: -#=20 -# file ::=3D desc_line* cmd_line events_line data_line+ summar= y_line -# desc_line ::=3D "desc:" ws? non_nl_string -# cmd_line ::=3D "cmd:" ws? cmd -# events_line ::=3D "events:" ws? (event ws)+ -# data_line ::=3D file_line | fn_line | count_line -# file_line ::=3D "fl=3D" filename -# fn_line ::=3D "fn=3D" fn_name -# count_line ::=3D line_num ws? (count ws)+ -# summary_line ::=3D "summary:" ws? (count ws)+ -# count ::=3D num | "." -#=20 -# where -# 'non_nl_string' is any string not containing a newline. -# 'cmd' is a string holding the command line of the profiled program. -# 'filename' and 'fn_name' are strings. -# 'num' and 'line_num' are decimal integers. -# 'ws' is whitespace. -#=20 -# The contents of the "desc:" lines are printed out at the top -# of the summary. This is a generic way of providing simulation -# specific information, eg. for giving the cache configuration for -# cache simulation. -#=20 -# More than one line of info can be presented for each file/fn/line numb= er. -# In such cases, the counts for the named events will be accumulated. -# -# Counts can be "." to represent zero. This makes the files easier to r= ead. -#=20 -# The number of counts in each 'line' and the 'summary_line' should not = exceed -# the number of events in the 'event_line'. If the number in each 'line= ' is -# less, cg_annotate treats those missing as though they were a "." entry= . -#=20 -# A 'file_line' changes the current file name. A 'fn_line' changes the -# current function name. A 'count_line' contains counts that pertain to= the -# current filename/fn_name. A 'file_line' and a 'fn_line' must appear -# before any 'count_line's to give the context of the first 'count_line'= . -#=20 -# Each 'file_line' will normally be immediately followed by a 'fn_line'. -# But it doesn't have to be. +# source line, grouped by files and functions. The details are in +# Cachegrind's manual. =20 #-----------------------------------------------------------------------= ----- # Performance improvements record, using cachegrind.out for cacheprof, d= oing no Modified: trunk/cachegrind/docs/cg-manual.xml =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 --- trunk/cachegrind/docs/cg-manual.xml 2006-10-21 18:25:12 UTC (rev 6331= ) +++ trunk/cachegrind/docs/cg-manual.xml 2006-10-21 22:22:59 UTC (rev 6332= ) @@ -6,12 +6,6 @@ <chapter id=3D"cg-manual" xreflabel=3D"Cachegrind: a cache-miss profiler= "> <title>Cachegrind: a cache profiler</title> =20 -<para>Detailed technical documentation on how Cachegrind works is -available in <xref linkend=3D"cg-tech-docs"/>. If you only want to know -how to <command>use</command> it, this is the page you need to -read.</para> - - <sect1 id=3D"cg-manual.cache" xreflabel=3D"Cache profiling"> <title>Cache profiling</title> =20 @@ -1018,18 +1012,101 @@ =20 </sect2> =20 +</sect1> =20 +<sect1> +<title>Implementation details</title> +This section talks about details you don't need to know about in order t= o +use Cachegrind, but may be of interest to some people. + <sect2> -<title>Todo</title> +<title>How Cachegrind works</title> +<para>The best reference for understanding how Cachegrind works is chapt= er 3 of +"Dynamic Binary Analysis and Instrumentation", by Nicholas Nethercote. = It +is available on the publications page of the Valgrind website.</para> +</sect2> =20 +<sect2> +<title>Cachegrind output file format</title> +<para>The file format is fairly straightforward, basically giving the +cost centre for every line, grouped by files and +functions. Total counts (eg. total cache accesses, total L1 +misses) are calculated when traversing this structure rather than +during execution, to save time; the cache simulation functions +are called so often that even one or two extra adds can make a +sizeable difference.</para> + +<para>The file format:</para> +<programlisting><![CDATA[ +file ::=3D desc_line* cmd_line events_line data_line+ summary_li= ne +desc_line ::=3D "desc:" ws? non_nl_string +cmd_line ::=3D "cmd:" ws? cmd +events_line ::=3D "events:" ws? (event ws)+ +data_line ::=3D file_line | fn_line | count_line +file_line ::=3D "fl=3D" filename +fn_line ::=3D "fn=3D" fn_name +count_line ::=3D line_num ws? (count ws)+ +summary_line ::=3D "summary:" ws? (count ws)+ +count ::=3D num | "."]]></programlisting> + +<para>Where:</para> <itemizedlist> <listitem> - <para>Program start-up/shut-down calls a lot of functions - that aren't interesting and just complicate the output. - Would be nice to exclude these somehow.</para> + <para><computeroutput>non_nl_string</computeroutput> is any + string not containing a newline.</para> </listitem> -</itemizedlist>=20 + <listitem> + <para><computeroutput>cmd</computeroutput> is a string holding the + command line of the profiled program.</para> + </listitem> + <listitem> + <para><computeroutput>filename</computeroutput> and + <computeroutput>fn_name</computeroutput> are strings.</para> + </listitem> + <listitem> + <para><computeroutput>num</computeroutput> and + <computeroutput>line_num</computeroutput> are decimal + numbers.</para> + </listitem> + <listitem> + <para><computeroutput>ws</computeroutput> is whitespace.</para> + </listitem> +</itemizedlist> =20 +<para>The contents of the "desc:" lines are printed out at the top +of the summary. This is a generic way of providing simulation +specific information, eg. for giving the cache configuration for +cache simulation.</para> + +<para>More than one line of info can be presented for each file/fn/line = number. +In such cases, the counts for the named events will be accumulated.</par= a> + +<para>Counts can be "." to represent zero. This makes the files easier = to +read.</para> + +<para>The number of counts in each +<computeroutput>line</computeroutput> and the +<computeroutput>summary_line</computeroutput> should not exceed +the number of events in the +<computeroutput>event_line</computeroutput>. If the number in +each <computeroutput>line</computeroutput> is less, cg_annotate +treats those missing as though they were a "." entry.</para> + +<para>A <computeroutput>file_line</computeroutput> changes the +current file name. A <computeroutput>fn_line</computeroutput> +changes the current function name. A +<computeroutput>count_line</computeroutput> contains counts that +pertain to the current filename/fn_name. A "fn=3D" +<computeroutput>file_line</computeroutput> and a +<computeroutput>fn_line</computeroutput> must appear before any +<computeroutput>count_line</computeroutput>s to give the context +of the first <computeroutput>count_line</computeroutput>s.</para> + +<para>Each <computeroutput>file_line</computeroutput> will normally be +immediately followed by a <computeroutput>fn_line</computeroutput>. But= it +doesn't have to be.</para> + + </sect2> =20 </sect1> Deleted: trunk/cachegrind/docs/cg-tech-docs.xml =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 --- trunk/cachegrind/docs/cg-tech-docs.xml 2006-10-21 18:25:12 UTC (rev 6= 331) +++ trunk/cachegrind/docs/cg-tech-docs.xml 2006-10-21 22:22:59 UTC (rev 6= 332) @@ -1,563 +0,0 @@ -<?xml version=3D"1.0"?> <!-- -*- sgml -*- --> -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<chapter id=3D"cg-tech-docs" xreflabel=3D"How Cachegrind works"> - -<title>How Cachegrind works</title> - -<sect1 id=3D"cg-tech-docs.profiling" xreflabel=3D"Cache profiling"> -<title>Cache profiling</title> - -<para>[Note: this document is now very old, and a lot of its contents ar= e out -of date, and misleading.]</para> - -<para>Valgrind is a very nice platform for doing cache profiling -and other kinds of simulation, because it converts horrible x86 -instructions into nice clean RISC-like UCode. For example, for -cache profiling we are interested in instructions that read and -write memory; in UCode there are only four instructions that do -this: <computeroutput>LOAD</computeroutput>, -<computeroutput>STORE</computeroutput>, -<computeroutput>FPU_R</computeroutput> and -<computeroutput>FPU_W</computeroutput>. By contrast, because of -the x86 addressing modes, almost every instruction can read or -write memory.</para> - -<para>Most of the cache profiling machinery is in the file -<filename>vg_cachesim.c</filename>.</para> - -<para>These notes are a somewhat haphazard guide to how -Valgrind's cache profiling works.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.costcentres" xreflabel=3D"Cost centres"> -<title>Cost centres</title> - -<para>Valgrind gathers cache profiling about every instruction -executed, individually. Each instruction has a <command>cost -centre</command> associated with it. There are two kinds of cost -centre: one for instructions that don't reference memory -(<computeroutput>iCC</computeroutput>), and one for instructions -that do (<computeroutput>idCC</computeroutput>):</para> - -<programlisting><![CDATA[ -typedef struct _CC { - ULong a; - ULong m1; - ULong m2; -} CC; - -typedef struct _iCC { - /* word 1 */ - UChar tag; - UChar instr_size; - - /* words 2+ */ - Addr instr_addr; - CC I; -} iCC; - =20 -typedef struct _idCC { - /* word 1 */ - UChar tag; - UChar instr_size; - UChar data_size; - - /* words 2+ */ - Addr instr_addr; - CC I;=20 - CC D;=20 -} idCC; ]]></programlisting> - -<para>Each <computeroutput>CC</computeroutput> has three fields -<computeroutput>a</computeroutput>, -<computeroutput>m1</computeroutput>, -<computeroutput>m2</computeroutput> for recording references, -level 1 misses and level 2 misses. Each of these is a 64-bit -<computeroutput>ULong</computeroutput> -- the numbers can get -very large, ie. greater than 4.2 billion allowed by a 32-bit -unsigned int.</para> - -<para>A <computeroutput>iCC</computeroutput> has one -<computeroutput>CC</computeroutput> for instruction cache -accesses. A <computeroutput>idCC</computeroutput> has two, one -for instruction cache accesses, and one for data cache -accesses.</para> - -<para>The <computeroutput>iCC</computeroutput> and -<computeroutput>dCC</computeroutput> structs also store -unchanging information about the instruction:</para> -<itemizedlist> - <listitem> - <para>An instruction-type identification tag (explained - below)</para> - </listitem> - <listitem> - <para>Instruction size</para> - </listitem> - <listitem> - <para>Data reference size - (<computeroutput>idCC</computeroutput> only)</para> - </listitem> - <listitem> - <para>Instruction address</para> - </listitem> -</itemizedlist> - -<para>Note that data address is not one of the fields for -<computeroutput>idCC</computeroutput>. This is because for many -memory-referencing instructions the data address can change each -time it's executed (eg. if it uses register-offset addressing). -We have to give this item to the cache simulation in a different -way (see Instrumentation section below). Some memory-referencing -instructions do always reference the same address, but we don't -try to treat them specialy in order to keep things simple.</para> - -<para>Also note that there is only room for recording info about -one data cache access in an -<computeroutput>idCC</computeroutput>. So what about -instructions that do a read then a write, such as:</para> -<programlisting><![CDATA[ -inc %(esi)]]></programlisting> - -<para>In a write-allocate cache, as simulated by Valgrind, the -write cannot miss, since it immediately follows the read which -will drag the block into the cache if it's not already there. So -the write access isn't really interesting, and Valgrind doesn't -record it. This means that Valgrind doesn't measure memory -references, but rather memory references that could miss in the -cache. This behaviour is the same as that used by the AMD Athlon -hardware counters. It also has the benefit of simplifying the -implementation -- instructions that read and write memory can be -treated like instructions that read memory.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.ccstore" xreflabel=3D"Storing cost-centres"> -<title>Storing cost-centres</title> - -<para>Cost centres are stored in a way that makes them very cheap -to lookup, which is important since one is looked up for every -original x86 instruction executed.</para> - -<para>Valgrind does JIT translations at the basic block level, -and cost centres are also setup and stored at the basic block -level. By doing things carefully, we store all the cost centres -for a basic block in a contiguous array, and lookup comes almost -for free.</para> - -<para>Consider this part of a basic block (for exposition -purposes, pretend it's an entire basic block):</para> -<programlisting><![CDATA[ -movl $0x0,%eax -movl $0x99, -4(%ebp)]]></programlisting> - -<para>The translation to UCode looks like this:</para> -<programlisting><![CDATA[ -MOVL $0x0, t20 -PUTL t20, %EAX -INCEIPo $5 - -LEA1L -4(t4), t14 -MOVL $0x99, t18 -STL t18, (t14) -INCEIPo $7]]></programlisting> - -<para>The first step is to allocate the cost centres. This -requires a preliminary pass to count how many x86 instructions -were in the basic block, and their types (and thus sizes). UCode -translations for single x86 instructions are delimited by the -<computeroutput>INCEIPo</computeroutput> instruction, the -argument of which gives the byte size of the instruction (note -that lazy INCEIP updating is turned off to allow this).</para> - -<para>We can tell if an x86 instruction references memory by -looking for <computeroutput>LDL</computeroutput> and -<computeroutput>STL</computeroutput> UCode instructions, and thus -what kind of cost centre is required. From this we can determine -how many cost centres we need for the basic block, and their -sizes. We can then allocate them in a single array.</para> - -<para>Consider the example code above. After the preliminary -pass, we know we need two cost centres, one -<computeroutput>iCC</computeroutput> and one -<computeroutput>dCC</computeroutput>. So we allocate an array to -store these which looks like this:</para> - -<programlisting><![CDATA[ -|(uninit)| tag (1 byte) -|(uninit)| instr_size (1 bytes) -|(uninit)| (padding) (2 bytes) -|(uninit)| instr_addr (4 bytes) -|(uninit)| I.a (8 bytes) -|(uninit)| I.m1 (8 bytes) -|(uninit)| I.m2 (8 bytes) - -|(uninit)| tag (1 byte) -|(uninit)| instr_size (1 byte) -|(uninit)| data_size (1 byte) -|(uninit)| (padding) (1 byte) -|(uninit)| instr_addr (4 bytes) -|(uninit)| I.a (8 bytes) -|(uninit)| I.m1 (8 bytes) -|(uninit)| I.m2 (8 bytes) -|(uninit)| D.a (8 bytes) -|(uninit)| D.m1 (8 bytes) -|(uninit)| D.m2 (8 bytes)]]></programlisting> - -<para>(We can see now why we need tags to distinguish between the -two types of cost centres.)</para> - -<para>We also record the size of the array. We look up the debug -info of the first instruction in the basic block, and then stick -the array into a table indexed by filename and function name. -This makes it easy to dump the information quickly to file at the -end.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.instrum" xreflabel=3D"Instrumentation"> -<title>Instrumentation</title> - -<para>The instrumentation pass has two main jobs:</para> - -<orderedlist> - <listitem> - <para>Fill in the gaps in the allocated cost centres.</para> - </listitem> - <listitem> - <para>Add UCode to call the cache simulator for each - instruction.</para> - </listitem> -</orderedlist> - -<para>The instrumentation pass steps through the UCode and the -cost centres in tandem. As each original x86 instruction's UCode -is processed, the appropriate gaps in the instructions cost -centre are filled in, for example:</para> - -<programlisting><![CDATA[ -|INSTR_CC| tag (1 byte) -|5 | instr_size (1 bytes) -|(uninit)| (padding) (2 bytes) -|i_addr1 | instr_addr (4 bytes) -|0 | I.a (8 bytes) -|0 | I.m1 (8 bytes) -|0 | I.m2 (8 bytes) - -|WRITE_CC| tag (1 byte) -|7 | instr_size (1 byte) -|4 | data_size (1 byte) -|(uninit)| (padding) (1 byte) -|i_addr2 | instr_addr (4 bytes) -|0 | I.a (8 bytes) -|0 | I.m1 (8 bytes) -|0 | I.m2 (8 bytes) -|0 | D.a (8 bytes) -|0 | D.m1 (8 bytes) -|0 | D.m2 (8 bytes)]]></programlisting> - -<para>(Note that this step is not performed if a basic block is -re-translated; see <xref linkend=3D"cg-tech-docs.retranslations"/> for -more information.)</para> - -<para>GCC inserts padding before the -<computeroutput>instr_size</computeroutput> field so that it is -word aligned.</para> - -<para>The instrumentation added to call the cache simulation -function looks like this (instrumentation is indented to -distinguish it from the original UCode):</para> - -<programlisting><![CDATA[ -MOVL $0x0, t20 -PUTL t20, %EAX - PUSHL %eax - PUSHL %ecx - PUSHL %edx - MOVL $0x4091F8A4, t46 # address of 1st CC - PUSHL t46 - CALLMo $0x12 # second cachesim function - CLEARo $0x4 - POPL %edx - POPL %ecx - POPL %eax -INCEIPo $5 - -LEA1L -4(t4), t14 -MOVL $0x99, t18 - MOVL t14, t42 -STL t18, (t14) - PUSHL %eax - PUSHL %ecx - PUSHL %edx - PUSHL t42 - MOVL $0x4091F8C4, t44 # address of 2nd CC - PUSHL t44 - CALLMo $0x13 # second cachesim function - CLEARo $0x8 - POPL %edx - POPL %ecx - POPL %eax -INCEIPo $7]]></programlisting> - -<para>Consider the first instruction's UCode. Each call is -surrounded by three <computeroutput>PUSHL</computeroutput> and -<computeroutput>POPL</computeroutput> instructions to save and -restore the caller-save registers. Then the address of the -instruction's cost centre is pushed onto the stack, to be the -first argument to the cache simulation function. The address is -known at this point because we are doing a simultaneous pass -through the cost centre array. This means the cost centre lookup -for each instruction is almost free (just the cost of pushing an -argument for a function call). Then the call to the cache -simulation function for non-memory-reference instructions is made -(note that the <computeroutput>CALLMo</computeroutput> -UInstruction takes an offset into a table of predefined -functions; it is not an absolute address), and the single -argument is <computeroutput>CLEAR</computeroutput>ed from the -stack.</para> - -<para>The second instruction's UCode is similar. The only -difference is that, as mentioned before, we have to pass the -address of the data item referenced to the cache simulation -function too. This explains the <computeroutput>MOVL t14, -t42</computeroutput> and <computeroutput>PUSHL -t42</computeroutput> UInstructions. (Note that the seemingly -redundant <computeroutput>MOV</computeroutput>ing will probably -be optimised away during register allocation.)</para> - -<para>Note that instead of storing unchanging information about -each instruction (instruction size, data size, etc) in its cost -centre, we could have passed in these arguments to the simulation -function. But this would slow the calls down (two or three extra -arguments pushed onto the stack). Also it would bloat the UCode -instrumentation by amounts similar to the space required for them -in the cost centre; bloated UCode would also fill the translation -cache more quickly, requiring more translations for large -programs and slowing them down more.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.retranslations"=20 - xreflabel=3D"Handling basic block retranslations"> -<title>Handling basic block retranslations</title> - -<para>The above description ignores one complication. Valgrind -has a limited size cache for basic block translations; if it -fills up, old translations are discarded. If a discarded basic -block is executed again, it must be re-translated.</para> - -<para>However, we can't use this approach for profiling -- we -can't throw away cost centres for instructions in the middle of -execution! So when a basic block is translated, we first look -for its cost centre array in the hash table. If there is no cost -centre array, it must be the first translation, so we proceed as -described above. But if there is a cost centre array already, it -must be a retranslation. In this case, we skip the cost centre -allocation and initialisation steps, but still do the UCode -instrumentation step.</para> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.cachesim" xreflabel=3D"The cache simulation"> -<title>The cache simulation</title> - -<para>The cache simulation is fairly straightforward. It just -tracks which memory blocks are in the cache at the moment (it -doesn't track the contents, since that is irrelevant).</para> - -<para>The interface to the simulation is quite clean. The -functions called from the UCode contain calls to the simulation -functions in the files -<filename>vg_cachesim_{I1,D1,L2}.c</filename>; these calls are -inlined so that only one function call is done per simulated x86 -instruction. The file <filename>vg_cachesim.c</filename> simply -<computeroutput>#include</computeroutput>s the three files -containing the simulation, which makes plugging in new cache -simulations is very easy -- you just replace the three files and -recompile.</para> - -</sect1> - - -<sect1 id=3D"cg-tech-docs.output" xreflabel=3D"Output"> -<title>Output</title> - -<para>Output is fairly straightforward, basically printing the -cost centre for every instruction, grouped by files and -functions. Total counts (eg. total cache accesses, total L1 -misses) are calculated when traversing this structure rather than -during execution, to save time; the cache simulation functions -are called so often that even one or two extra adds can make a -sizeable difference.</para> - -<para>Input file has the following format:</para> -<programlisting><![CDATA[ -file ::=3D desc_line* cmd_line events_line data_line+ summary_li= ne -desc_line ::=3D "desc:" ws? non_nl_string -cmd_line ::=3D "cmd:" ws? cmd -events_line ::=3D "events:" ws? (event ws)+ -data_line ::=3D file_line | fn_line | count_line -file_line ::=3D ("fl=3D" | "fi=3D" | "fe=3D") filename -fn_line ::=3D "fn=3D" fn_name -count_line ::=3D line_num ws? (count ws)+ -summary_line ::=3D "summary:" ws? (count ws)+ -count ::=3D num | "."]]></programlisting> - -<para>Where:</para> -<itemizedlist> - <listitem> - <para><computeroutput>non_nl_string</computeroutput> is any - string not containing a newline.</para> - </listitem> - <listitem> - <para><computeroutput>cmd</computeroutput> is a command line - invocation.</para> - </listitem> - <listitem> - <para><computeroutput>filename</computeroutput> and - <computeroutput>fn_name</computeroutput> can be anything.</para> - </listitem> - <listitem> - <para><computeroutput>num</computeroutput> and - <computeroutput>line_num</computeroutput> are decimal - numbers.</para> - </listitem> - <listitem> - <para><computeroutput>ws</computeroutput> is whitespace.</para> - </listitem> - <listitem> - <para><computeroutput>nl</computeroutput> is a newline.</para> - </listitem> - -</itemizedlist> - -<para>The contents of the "desc:" lines is printed out at the top -of the summary. This is a generic way of providing simulation -specific information, eg. for giving the cache configuration for -cache simulation.</para> - -<para>Counts can be "." to represent "N/A", eg. the number of -write misses for an instruction that doesn't write to -memory.</para> - -<para>The number of counts in each -<computeroutput>line</computeroutput> and the -<computeroutput>summary_line</computeroutput> should not exceed -the number of events in the -<computeroutput>event_line</computeroutput>. If the number in -each <computeroutput>line</computeroutput> is less, cg_annotate -treats those missing as though they were a "." entry.</para> - -<para>A <computeroutput>file_line</computeroutput> changes the -current file name. A <computeroutput>fn_line</computeroutput> -changes the current function name. A -<computeroutput>count_line</computeroutput> contains counts that -pertain to the current filename/fn_name. A "fn=3D" -<computeroutput>file_line</computeroutput> and a -<computeroutput>fn_line</computeroutput> must appear before any -<computeroutput>count_line</computeroutput>s to give the context -of the first <computeroutput>count_line</computeroutput>s.</para> - -<para>Each <computeroutput>file_line</computeroutput> should be -immediately followed by a -<computeroutput>fn_line</computeroutput>. "fi=3D" -<computeroutput>file_lines</computeroutput> are used to switch -filenames for inlined functions; "fe=3D" -<computeroutput>file_lines</computeroutput> are similar, but are -put at the end of a basic block in which the file name hasn't -been switched back to the original file name. (fi and fe lines -behave the same, they are only distinguished to help -debugging.)</para> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.summary"=20 - xreflabel=3D"Summary of performance features"> -<title>Summary of performance features</title> - -<para>Quite a lot of work has gone into making the profiling as -fast as possible. This is a summary of the important -features:</para> - -<itemizedlist> - - <listitem> - <para>The basic block-level cost centre storage allows almost - free cost centre lookup.</para> - </listitem> - =20 - <listitem> - <para>Only one function call is made per instruction - simulated; even this accounts for a sizeable percentage of - execution time, but it seems unavoidable if we want - flexibility in the cache simulator.</para> - </listitem> - - <listitem> - <para>Unchanging information about an instruction is stored - in its cost centre, avoiding unnecessary argument pushing, - and minimising UCode instrumentation bloat.</para> - </listitem> - - <listitem> - <para>Summary counts are calculated at the end, rather than - during execution.</para> - </listitem> - - <listitem> - <para>The <computeroutput>cachegrind.out</computeroutput> - output files can contain huge amounts of information; file - format was carefully chosen to minimise file sizes.</para> - </listitem> - -</itemizedlist> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.annotate" xreflabel=3D"Annotation"> -<title>Annotation</title> - -<para>Annotation is done by cg_annotate. It is a fairly -straightforward Perl script that slurps up all the cost centres, -and then runs through all the chosen source files, printing out -cost centres with them. It too has been carefully optimised.</para> - -</sect1> - - - -<sect1 id=3D"cg-tech-docs.extensions" xreflabel=3D"Similar work, extensi= ons"> -<title>Similar work, extensions</title> - -<para>It would be relatively straightforward to do other -simulations and obtain line-by-line information about interesting -events. A good example would be branch prediction -- all -branches could be instrumented to interact with a branch -prediction simulator, using very similar techniques to those -described above.</para> - -<para>In particular, cg_annotate would not need to change -- the -file format is such that it is not specific to the cache -simulation, but could be used for any kind of line-by-line -information. The only part of cg_annotate that is specific to -the cache simulation is the name of the input file -(<computeroutput>cachegrind.out</computeroutput>), although it -would be very simple to add an option to control this.</para> - -</sect1> - -</chapter> Modified: trunk/docs/xml/tech-docs.xml =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 --- trunk/docs/xml/tech-docs.xml 2006-10-21 18:25:12 UTC (rev 6331) +++ trunk/docs/xml/tech-docs.xml 2006-10-21 22:22:59 UTC (rev 6332) @@ -19,8 +19,6 @@ =20 <xi:include href=3D"../../memcheck/docs/mc-tech-docs.xml" parse=3D"xml= " =20 xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> - <xi:include href=3D"../../cachegrind/docs/cg-tech-docs.xml" parse=3D"x= ml" =20 - xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> <xi:include href=3D"../../callgrind/docs/cl-format.xml" parse=3D"xml" = =20 xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> <xi:include href=3D"writing-tools.xml" parse=3D"xml" =20 |
|
From: Julian S. <js...@ac...> - 2006-10-21 22:12:36
|
gcc-3.3 seems to be markedly less enthusiastic about inlining than other versions -- both earlier and later versions. As Josef says, later gcc's don't show this problem. But I think using the INLINE macro might be a good thing since all those warning messages make it harder to see real errors (I aim to have a completely silent "make --quiet", apart from the printing of the top level directory names). J On Saturday 21 October 2006 16:30, Nicholas Nethercote wrote: > Josef, > > With gcc 3.3.4 I get a lot of 'inlining failed in call to X' messages from > GCC (see attachment). Some of them look like they are important for > Callgrind's speed. If they are, you might like to look at Memcheck's > INLINE macro which tries harder than usual to inline functions. > > Nick |
|
From: <sv...@va...> - 2006-10-21 18:25:17
|
Author: njn
Date: 2006-10-21 19:25:12 +0100 (Sat, 21 Oct 2006)
New Revision: 6331
Log:
- Update comments about Cachegrind file format.
- Be slightly more strict in accepting Cachegrind input files.
MERGED FROM TRUNK
Modified:
branches/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in
Modified: branches/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in
=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/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in 2006-10-21 18:=
22:35 UTC (rev 6330)
+++ branches/VALGRIND_3_2_BRANCH/cachegrind/cg_annotate.in 2006-10-21 18:=
25:12 UTC (rev 6331)
@@ -36,7 +36,7 @@
# cmd_line ::=3D "cmd:" ws? cmd
# events_line ::=3D "events:" ws? (event ws)+
# data_line ::=3D file_line | fn_line | count_line
-# file_line ::=3D ("fl=3D" | "fi=3D" | "fe=3D") filename
+# file_line ::=3D "fl=3D" filename
# fn_line ::=3D "fn=3D" fn_name
# count_line ::=3D line_num ws? (count ws)+
# summary_line ::=3D "summary:" ws? (count ws)+
@@ -54,8 +54,10 @@
# specific information, eg. for giving the cache configuration for
# cache simulation.
#=20
-# Counts can be "." to represent "N/A", eg. the number of write misses f=
or an
-# instruction that doesn't write to memory.
+# More than one line of info can be presented for each file/fn/line numb=
er.
+# In such cases, the counts for the named events will be accumulated.
+#
+# Counts can be "." to represent zero. This makes the files easier to r=
ead.
#=20
# The number of counts in each 'line' and the 'summary_line' should not =
exceed
# the number of events in the 'event_line'. If the number in each 'line=
' is
@@ -66,13 +68,8 @@
# current filename/fn_name. A 'file_line' and a 'fn_line' must appear
# before any 'count_line's to give the context of the first 'count_line'=
.
#=20
-# Each 'file_line' should be immediately followed by a 'fn_line'. "fi=3D=
"
-# 'file_lines' are used to switch filenames for inlined functions; "fe=3D=
"
-# 'file_lines' are similar, but are put at the end of a basic block in w=
hich
-# the file name hasn't been switched back to the original file name. (f=
i
-# and fe lines behave the same, they are only distinguished to help
-# debugging.) [Nb: "fi=3D" and "fe=3D" have not been produced by Cacheg=
rind for
-# some time, they are no longer necessary.]
+# Each 'file_line' will normally be immediately followed by a 'fn_line'.
+# But it doesn't have to be.
=20
#-----------------------------------------------------------------------=
-----
# Performance improvements record, using cachegrind.out for cacheprof, d=
oing no
@@ -362,14 +359,14 @@
}
=20
# Read "cmd:" line (Nb: will already be in $line from "desc:" loop a=
bove).
- ($line =3D~ s/cmd:\s+//) or die("Line $.: missing command line\n");
+ ($line =3D~ s/^cmd:\s+//) or die("Line $.: missing command line\n");
$cmd =3D $line;
chomp($cmd); # Remove newline
=20
# Read "events:" line. We make a temporary hash in which the Nth ev=
ent's
# value is N, which is useful for handling --show/--sort options bel=
ow.
$line =3D <INPUTFILE>;
- (defined $line && $line =3D~ s/events:\s+//)=20
+ (defined $line && $line =3D~ s/^events:\s+//)=20
or die("Line $.: missing events line\n");
@events =3D split(/\s+/, $line);
my %events;
|
|
From: <sv...@va...> - 2006-10-21 18:22:44
|
Author: njn
Date: 2006-10-21 19:22:35 +0100 (Sat, 21 Oct 2006)
New Revision: 6330
Log:
- Update comments about Cachegrind file format.
- Be slightly more strict in accepting Cachegrind input files.
Modified:
trunk/cachegrind/cg_annotate.in
Modified: trunk/cachegrind/cg_annotate.in
=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
--- trunk/cachegrind/cg_annotate.in 2006-10-20 22:54:20 UTC (rev 6329)
+++ trunk/cachegrind/cg_annotate.in 2006-10-21 18:22:35 UTC (rev 6330)
@@ -36,7 +36,7 @@
# cmd_line ::=3D "cmd:" ws? cmd
# events_line ::=3D "events:" ws? (event ws)+
# data_line ::=3D file_line | fn_line | count_line
-# file_line ::=3D ("fl=3D" | "fi=3D" | "fe=3D") filename
+# file_line ::=3D "fl=3D" filename
# fn_line ::=3D "fn=3D" fn_name
# count_line ::=3D line_num ws? (count ws)+
# summary_line ::=3D "summary:" ws? (count ws)+
@@ -54,8 +54,10 @@
# specific information, eg. for giving the cache configuration for
# cache simulation.
#=20
-# Counts can be "." to represent "N/A", eg. the number of write misses f=
or an
-# instruction that doesn't write to memory.
+# More than one line of info can be presented for each file/fn/line numb=
er.
+# In such cases, the counts for the named events will be accumulated.
+#
+# Counts can be "." to represent zero. This makes the files easier to r=
ead.
#=20
# The number of counts in each 'line' and the 'summary_line' should not =
exceed
# the number of events in the 'event_line'. If the number in each 'line=
' is
@@ -66,13 +68,8 @@
# current filename/fn_name. A 'file_line' and a 'fn_line' must appear
# before any 'count_line's to give the context of the first 'count_line'=
.
#=20
-# Each 'file_line' should be immediately followed by a 'fn_line'. "fi=3D=
"
-# 'file_lines' are used to switch filenames for inlined functions; "fe=3D=
"
-# 'file_lines' are similar, but are put at the end of a basic block in w=
hich
-# the file name hasn't been switched back to the original file name. (f=
i
-# and fe lines behave the same, they are only distinguished to help
-# debugging.) [Nb: "fi=3D" and "fe=3D" have not been produced by Cacheg=
rind for
-# some time, they are no longer necessary.]
+# Each 'file_line' will normally be immediately followed by a 'fn_line'.
+# But it doesn't have to be.
=20
#-----------------------------------------------------------------------=
-----
# Performance improvements record, using cachegrind.out for cacheprof, d=
oing no
@@ -362,14 +359,14 @@
}
=20
# Read "cmd:" line (Nb: will already be in $line from "desc:" loop a=
bove).
- ($line =3D~ s/cmd:\s+//) or die("Line $.: missing command line\n");
+ ($line =3D~ s/^cmd:\s+//) or die("Line $.: missing command line\n");
$cmd =3D $line;
chomp($cmd); # Remove newline
=20
# Read "events:" line. We make a temporary hash in which the Nth ev=
ent's
# value is N, which is useful for handling --show/--sort options bel=
ow.
$line =3D <INPUTFILE>;
- (defined $line && $line =3D~ s/events:\s+//)=20
+ (defined $line && $line =3D~ s/^events:\s+//)=20
or die("Line $.: missing events line\n");
@events =3D split(/\s+/, $line);
my %events;
|
|
From: Josef W. <Jos...@gm...> - 2006-10-21 15:59:33
|
On Saturday 21 October 2006 17:30, Nicholas Nethercote wrote: > Josef, > > With gcc 3.3.4 I get a lot of 'inlining failed in call to X' messages from > GCC (see attachment). Some of them look like they are important for > Callgrind's speed. Yes, the ones from sim.c could be important. I do not get such warnings with GCC 4.1 here on Suse 10.1. I think I'll have to do some self-hosting experiments with/without inlining these functions. > If they are, you might like to look at Memcheck's INLINE > macro which tries harder than usual to inline functions. Ah, I didn't know about the attribute "always_inline". Thanks for the tip, Josef > > Nick > |
|
From: <js...@ac...> - 2006-10-21 15:40:51
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-10-21 17:24:13 CEST 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 == 220 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) 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-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |
|
From: Nicholas N. <nj...@cs...> - 2006-10-21 15:30:26
|
Josef, With gcc 3.3.4 I get a lot of 'inlining failed in call to X' messages from GCC (see attachment). Some of them look like they are important for Callgrind's speed. If they are, you might like to look at Memcheck's INLINE macro which tries harder than usual to inline functions. Nick |
|
From: <js...@ac...> - 2006-10-21 14:42:34
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-10-21 11:11:35 CEST 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 == 220 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) 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-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |
|
From: <js...@ac...> - 2006-10-21 14:33:08
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-10-21 09:00:01 BST 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 == 214 tests, 12 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2006-10-21 09:28:15
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-10-21 11:11:35 CEST 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 == 220 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) 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-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |
|
From: <js...@ac...> - 2006-10-21 04:04:03
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-10-21 04:30:02 BST 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 == 244 tests, 8 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2006-10-21 02:45:53
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-10-21 03:30:06 BST 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 == 246 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-10-21 02:26:29
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-10-21 03:10:04 BST 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 == 274 tests, 22 stderr failures, 1 stdout failure, 0 posttest failures == 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/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_creat (stderr) none/tests/fdleak_dup (stderr) none/tests/fdleak_dup2 (stderr) none/tests/fdleak_fcntl (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/fdleak_open (stderr) none/tests/fdleak_pipe (stderr) none/tests/fdleak_socketpair (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/rlimit_nofile (stderr) |
|
From: Tom H. <th...@cy...> - 2006-10-21 02:26:21
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-10-21 03:15:03 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccDINLBq.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccDINLBq.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.27330/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.27330/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.27330/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.27330/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.27330/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccqjfDzo.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccqjfDzo.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.27330/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.27330/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.27330/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.27330/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.27330/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 21 03:21:08 2006 --- new.short Sat Oct 21 03:26:15 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccqjfDzo.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccqjfDzo.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccDINLBq.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccDINLBq.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-10-21 02:25:31
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-10-21 03:00:02 BST 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 == 276 tests, 15 stderr failures, 1 stdout failure, 0 posttest failures == 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/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 276 tests, 15 stderr failures, 2 stdout failures, 0 posttest failures == 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/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/tls (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 21 03:14:40 2006 --- new.short Sat Oct 21 03:25:22 2006 *************** *** 8,10 **** ! == 276 tests, 15 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) --- 8,10 ---- ! == 276 tests, 15 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) *************** *** 25,27 **** none/tests/mremap2 (stdout) - none/tests/tls (stdout) --- 25,26 ---- |
|
From: Tom H. <th...@cy...> - 2006-10-21 02:20:20
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-10-21 03:05:08 BST 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 == 274 tests, 14 stderr failures, 1 stdout failure, 0 posttest failures == 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/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |