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
(22) |
2
(24) |
|
3
(19) |
4
(20) |
5
(17) |
6
(20) |
7
(13) |
8
|
9
|
|
10
(10) |
11
(35) |
12
(20) |
13
(6) |
14
(19) |
15
|
16
|
|
17
(2) |
18
(3) |
19
(12) |
20
(1) |
21
(14) |
22
(2) |
23
(13) |
|
24
(2) |
25
(16) |
26
(17) |
27
(21) |
28
(17) |
29
(17) |
30
(14) |
|
31
(15) |
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2013-03-13 22:30:18
|
On Wed, 2013-03-13 at 14:18 +0400, Дмитрий Дьяченко wrote: > he correct way to fix diff fail? [assume that > gcc-4.5+ compiles origin5-bz2 correctly] > 1) change optimization level from -O to -O0 > 2) add once more origin5-bz2.stderr.exp > > case 1) solve diff between 'client request' and 'heap allocation' but > add 4 new err.msgs and hence require add/change expected stderr.out > too > > case 2) add one more file > > It's interesting that gcc-4.7/PPC64 and gcc-4.6/s390x PASS. Does switching to -O0 reduce the nr of stderr different files ? Switching to -O0 will slow down this test, but by how much ? (I believe this test is not used anymore for performance testing, so not that relevant anymore). However, maybe -O1 reduces the nr of different stderr files, without slowing down too much ? (test takes longer when not giving an argument to origin5-bz2) Philippe |
|
From: <sv...@va...> - 2013-03-13 22:03:38
|
philippe 2013-03-13 22:03:31 +0000 (Wed, 13 Mar 2013)
New Revision: 13327
Log:
Document that user level client stack switches might cause crashes
and that these crahses might be avoided using VALGRIND_STACK_REGISTER
See bug 316613
Modified files:
trunk/docs/xml/manual-core-adv.xml
trunk/docs/xml/manual-core.xml
Modified: trunk/docs/xml/manual-core.xml (+10 -7)
===================================================================
--- trunk/docs/xml/manual-core.xml 2013-03-13 21:44:07 +00:00 (rev 13326)
+++ trunk/docs/xml/manual-core.xml 2013-03-13 22:03:31 +00:00 (rev 13327)
@@ -2609,13 +2609,16 @@
<para><computeroutput>Warning: client switching stacks?</computeroutput></para>
<para>Valgrind spotted such a large change in the stack pointer
- that it guesses the client is switching to
- a different stack. At this point it makes a kludgey guess where the
- base of the new stack is, and sets memory permissions accordingly.
- You may get many bogus error messages following this, if Valgrind
- guesses wrong. At the moment "large change" is defined as a change
- of more that 2000000 in the value of the
- stack pointer register.</para>
+ that it guesses the client is switching to a different stack. At
+ this point it makes a kludgey guess where the base of the new
+ stack is, and sets memory permissions accordingly. At the moment
+ "large change" is defined as a change of more that 2000000 in the
+ value of the stack pointer register. If Valgrind guesses wrong,
+ you may get many bogus error messages following this and/or have
+ crashes in the stack trace recording code. You might avoid these
+ problems by informing Valgrind about the stack bounds using
+ VALGRIND_STACK_REGISTER client request. </para>
+
</listitem>
<listitem>
Modified: trunk/docs/xml/manual-core-adv.xml (+6 -5)
===================================================================
--- trunk/docs/xml/manual-core-adv.xml 2013-03-13 21:44:07 +00:00 (rev 13326)
+++ trunk/docs/xml/manual-core-adv.xml 2013-03-13 22:03:31 +00:00 (rev 13327)
@@ -247,11 +247,12 @@
between start and end is a unique stack. Returns a stack identifier
that can be used with other
<computeroutput>VALGRIND_STACK_*</computeroutput> calls.</para>
- <para>Valgrind will use this information to determine if a change to
- the stack pointer is an item pushed onto the stack or a change over
- to a new stack. Use this if you're using a user-level thread package
- and are noticing spurious errors from Valgrind about uninitialized
- memory reads.</para>
+ <para>Valgrind will use this information to determine if a change
+ to the stack pointer is an item pushed onto the stack or a change
+ over to a new stack. Use this if you're using a user-level thread
+ package and are noticing crashes in stack trace recording or
+ spurious errors from Valgrind about uninitialized memory
+ reads.</para>
<para><command>Warning:</command> Unfortunately, this client request is
unreliable and best avoided.</para>
|
|
From: <sv...@va...> - 2013-03-13 21:44:18
|
philippe 2013-03-13 21:44:07 +0000 (Wed, 13 Mar 2013)
New Revision: 13326
Log:
Fix 316535 Use of |signed int| instead of (unsigned) |size_t| in messages...
* when SEGV trapped, report the main thread size as an unsigned size_t
* Similar for memcheck overlap errors
For example, for the 2 calls:
memcpy(&a, &a, 2147483648UL);
memcpy(&a, &a, -1); // silently accepted by gcc 4.4.4 -Wall
// while the 3rd arg is supposed to be a size_t
we now obtain (on a 32 bit system)
Source and destination overlap in memcpy(0xbe97113f, 0xbe97113f, 2147483648)
Source and destination overlap in memcpy(0xbef6d13f, 0xbef6d13f, 4294967295)
instead of
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -2147483648)
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -1)
Do not ask me why
memcpy(&a, &a, -1);
is supposed to be accepted/acceptable/valid code.
Modified files:
trunk/NEWS
trunk/coregrind/m_signals.c
trunk/memcheck/mc_errors.c
Modified: trunk/coregrind/m_signals.c (+2 -2)
===================================================================
--- trunk/coregrind/m_signals.c 2013-03-12 01:32:40 +00:00 (rev 13325)
+++ trunk/coregrind/m_signals.c 2013-03-13 21:44:07 +00:00 (rev 13326)
@@ -1716,8 +1716,8 @@
// FIXME: assumes main ThreadId == 1
if (VG_(is_valid_tid)(1)) {
VG_(umsg)(
- " The main thread stack size used in this run was %d.\n",
- (Int)VG_(threads)[1].client_stack_szB);
+ " The main thread stack size used in this run was %lu.\n",
+ VG_(threads)[1].client_stack_szB);
}
}
}
Modified: trunk/memcheck/mc_errors.c (+5 -5)
===================================================================
--- trunk/memcheck/mc_errors.c 2013-03-12 01:32:40 +00:00 (rev 13325)
+++ trunk/memcheck/mc_errors.c 2013-03-13 21:44:07 +00:00 (rev 13326)
@@ -235,9 +235,9 @@
// Call to strcpy, memcpy, etc, with overlapping blocks.
struct {
- Addr src; // Source block
- Addr dst; // Destination block
- Int szB; // Size in bytes; 0 if unused.
+ Addr src; // Source block
+ Addr dst; // Destination block
+ SizeT szB; // Size in bytes; 0 if unused.
} Overlap;
// A memory leak.
@@ -845,7 +845,7 @@
extra->Err.Overlap.dst, extra->Err.Overlap.src );
} else {
emit( " <what>Source and destination overlap "
- "in %s(%#lx, %#lx, %d)</what>\n",
+ "in %s(%#lx, %#lx, %lu)</what>\n",
VG_(get_error_string)(err),
extra->Err.Overlap.dst, extra->Err.Overlap.src,
extra->Err.Overlap.szB );
@@ -857,7 +857,7 @@
VG_(get_error_string)(err),
extra->Err.Overlap.dst, extra->Err.Overlap.src );
} else {
- emit( "Source and destination overlap in %s(%#lx, %#lx, %d)\n",
+ emit( "Source and destination overlap in %s(%#lx, %#lx, %lu)\n",
VG_(get_error_string)(err),
extra->Err.Overlap.dst, extra->Err.Overlap.src,
extra->Err.Overlap.szB );
Modified: trunk/NEWS (+1 -0)
===================================================================
--- trunk/NEWS 2013-03-12 01:32:40 +00:00 (rev 13325)
+++ trunk/NEWS 2013-03-13 21:44:07 +00:00 (rev 13326)
@@ -217,6 +217,7 @@
FIXED 13294
315545 [390] (find_TTEntry_from_hcode): Assertion '(UChar*)sec->tt[tteNo].tcptr <= (UChar*)hcode' failed
+316535 [390] Use of |signed int| instead of (unsigned) |size_t| in valgrind messages...
315959 [390] valgrind man page has bogus SGCHECK (and no BBV) OPTIONS section
316144 [390] valgrind.1 manpage contains unknown ??? strings for some core option references
316145 [390] callgrind command line options in manpage reference (unknown) callgrind manual
|
|
From: Дмитрий Д. <di...@gm...> - 2013-03-13 10:18:55
|
Hi!
Last years testsuite is in nice shape :)
But there are some fails.
One common fail is memcheck/origin5-bz2 at x86_64 with 'new' gcc (>=4.5)
Reduced diff:
- Uninitialised value was created by a client request
+ Uninitialised value was created by a heap allocation
My question is: What is the correct way to fix diff fail? [assume that
gcc-4.5+ compiles origin5-bz2 correctly]
1) change optimization level from -O to -O0
2) add once more origin5-bz2.stderr.exp
case 1) solve diff between 'client request' and 'heap allocation' but
add 4 new err.msgs and hence require add/change expected stderr.out
too
case 2) add one more file
It's interesting that gcc-4.7/PPC64 and gcc-4.6/s390x PASS.
Thanks,
Dmitry
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2013-03-11 21:42:54.480969900 -0500
+++ origin5-bz2.stderr.out 2013-03-11 21:48:27.989810912 -0500
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
FAIL x86_64
gcc-4.5.1 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22421
gcc-4.6.3 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22419
gcc-4.6.3 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22418
gcc-4.7.2 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22416
gcc-4.7.2 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22415
gcc-4.7.2 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22413
gcc-4.8.0 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22412
PASS PPC64
gcc-4.7.2 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22420
PASS S390x
gcc-4.6.1 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/22414
|
|
From: Josef W. <Jos...@gm...> - 2013-03-13 10:00:42
|
Am 13.03.2013 03:30, schrieb Matt Wette: > You are correct that it does not capture a good picture of superscalar processors. > I feel that adding that capability may be doable as future improvement. One could > have a table that provides some information on latency and through put of the pipelines > and maybe rules for parallel processing. However, what I'm after is estimates that are > better than nothing or super-crude estimates. For SoCs/embedded, your approach may be fine. Modern general purpose processors is a completely different game. There it is better to assume that everything is pipelined and out-of-order works more or less perfect, ie. only throughputs and long-lasting events (memory accesses) are limiting. > One critical feature, for the use-case I'm looking to help, is the ability to estimate cycles > for a specific part of the code. Expanding lackey will not do the trick. You could add two client requests to lackey to reset/read a counter. Still it's a bit weird because the implementation of the client request itself will influence your counter. Your volatile variable approach is really broken: Assume that the counter variable needs to be read with two read operations (lower/upper part). Now if your tool increments the counter between reading lower and upper half, sometimes you get bogus values. The only other way > I could see would be to have command-line options to have counters for specific functions. > Still, I think this option provides the most flexibility. Client requests and command line flags often can do the same things, and are convenience for the user. You could have a client request which tells your tool to capture a cycle estimation for a given function. Josef > > Matt > > > On Mar 12, 2013, at 3:51 AM, Josef Weidendorfer wrote: > >> Am 11.03.2013 23:08, schrieb Matt Wette: >>> The xprof tool I proposed several weeks ago is available as a patch to >>> valgrind-3.8.1. >>> >>> https://code.google.com/p/valgrind-xprof/downloads/list >>> >>> I'm assuming the chance of this being rolled into the valgrind >>> distribution is near-zero. >> >> I just had a look: I see that you assign each VEX IR a cycle >> penalty, and maintain a counter which increments according to executed >> code. >> >> The resulting cycle latency only makes sense if you have >> a very simple processor, without superscalarity, with in-order >> execution and no caches. The model does not include any >> throughput constrains or conflict penalities. >> Still the tool goes a long way to cover every VEX IR. >> Wouldn't it be enough to have just a few instruction classes? >> >> Passing the results back to the client application via a >> volatile variable really is weird (you are influencing what you >> measure). Why not a separate output? Or as return value of a client >> request? >> The only runtime information you really need is the execution >> count of SBs. Everything else can be done with post-processing, >> making the tool much faster. >> >> Regarding any chance for merging: this is not my decision, >> but the current, separate tool seems to have limited value. >> A simplified version of your approach may be interesting as >> add-on to cache simulation. Another suggestion: the lackey tool >> ("--detailed-counts=yes") prints out some statistics which could >> be refined to show counts for different AluOps, and maintain a >> counter using cycle penalities. This way, it may provide the same >> results as your tool. >> >> You already have it public on google code. Instead of a patch to >> a fixed Valgrind version, you could make a separate package out of it: >> You can detect existance of an installed Valgrind in a configure >> script via pkg-config, and compile/link with the installed Valgrind >> headers/libraries. >> >> Josef >> >> >>> >>> Date: Wed, 20 Feb 2013 19:48:18 -0800 >>> From: Matthew Wette <mw...@al... >>> <mailto:mw...@al...>> >>> Subject: [Valgrind-developers] proposed new tool: xprof >>> To: val...@li... >>> <mailto:val...@li...> >>> Message-ID: <4D3...@al... >>> <mailto:4D3...@al...>> >>> Content-Type: text/plain; charset=us-ascii >>> >>> Hi Folks, >>> >>> I have been working on a new valgrind tool and want to get feedback on >>> approach and chances for getting this rolled into the distribution. If >>> this has potential, I'd like to get feedback on ideas for user options, etc. >>> >>> I'm calling the tool "xprof" (prefix "xp"). It is an execution profiler. >>> >>> The context for tool use is the following: >>> The user develops code on his desktop computer, but the downstream >>> target is an embedded real-time application. He develops the code >>> in a (physics based) simulation of the target environment. For >>> example, he develops a a fuel-injection algorithm for an automobile >>> engine. Early in the project the embedded real-time group wants an >>> estimate of the CPU utilization of his algorithm. The algorithm is >>> difficult to run without the context of the enviroment simulation, >>> so he has trouble answering this question. Typically, he can only >>> make crude estimates. Enter valgrind/xprof. This tool would allow >>> the user to quickly provide a better CPU loading estimate within >>> his simulation environment by providing cycle count estimates of >>> specified regions of code. We are not after exact clock counts, but >>> something better than crude flop estimates. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >>> endpoint security space. For insight on selecting the right partner to >>> tackle endpoint security challenges, access the full report. >>> http://p.sf.net/sfu/symantec-dev2dev >>> >>> >>> >>> _______________________________________________ >>> Valgrind-developers mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >>> >> >> >> ------------------------------------------------------------------------------ >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >> endpoint security space. For insight on selecting the right partner to >> tackle endpoint security challenges, access the full report. >> http://p.sf.net/sfu/symantec-dev2dev >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
|
From: Matt W. <mw...@al...> - 2013-03-13 02:30:58
|
Josef, Thanks for taking time to check this out. You are correct that it does not capture a good picture of superscalar processors. I feel that adding that capability may be doable as future improvement. One could have a table that provides some information on latency and through put of the pipelines and maybe rules for parallel processing. However, what I'm after is estimates that are better than nothing or super-crude estimates. One critical feature, for the use-case I'm looking to help, is the ability to estimate cycles for a specific part of the code. Expanding lackey will not do the trick. The only other way I could see would be to have command-line options to have counters for specific functions. Still, I think this option provides the most flexibility. Matt On Mar 12, 2013, at 3:51 AM, Josef Weidendorfer wrote: > Am 11.03.2013 23:08, schrieb Matt Wette: >> The xprof tool I proposed several weeks ago is available as a patch to >> valgrind-3.8.1. >> >> https://code.google.com/p/valgrind-xprof/downloads/list >> >> I'm assuming the chance of this being rolled into the valgrind >> distribution is near-zero. > > I just had a look: I see that you assign each VEX IR a cycle > penalty, and maintain a counter which increments according to executed > code. > > The resulting cycle latency only makes sense if you have > a very simple processor, without superscalarity, with in-order > execution and no caches. The model does not include any > throughput constrains or conflict penalities. > Still the tool goes a long way to cover every VEX IR. > Wouldn't it be enough to have just a few instruction classes? > > Passing the results back to the client application via a > volatile variable really is weird (you are influencing what you > measure). Why not a separate output? Or as return value of a client > request? > The only runtime information you really need is the execution > count of SBs. Everything else can be done with post-processing, > making the tool much faster. > > Regarding any chance for merging: this is not my decision, > but the current, separate tool seems to have limited value. > A simplified version of your approach may be interesting as > add-on to cache simulation. Another suggestion: the lackey tool > ("--detailed-counts=yes") prints out some statistics which could > be refined to show counts for different AluOps, and maintain a > counter using cycle penalities. This way, it may provide the same > results as your tool. > > You already have it public on google code. Instead of a patch to > a fixed Valgrind version, you could make a separate package out of it: > You can detect existance of an installed Valgrind in a configure > script via pkg-config, and compile/link with the installed Valgrind > headers/libraries. > > Josef > > >> >> Date: Wed, 20 Feb 2013 19:48:18 -0800 >> From: Matthew Wette <mw...@al... >> <mailto:mw...@al...>> >> Subject: [Valgrind-developers] proposed new tool: xprof >> To: val...@li... >> <mailto:val...@li...> >> Message-ID: <4D3...@al... >> <mailto:4D3...@al...>> >> Content-Type: text/plain; charset=us-ascii >> >> Hi Folks, >> >> I have been working on a new valgrind tool and want to get feedback on >> approach and chances for getting this rolled into the distribution. If >> this has potential, I'd like to get feedback on ideas for user options, etc. >> >> I'm calling the tool "xprof" (prefix "xp"). It is an execution profiler. >> >> The context for tool use is the following: >> The user develops code on his desktop computer, but the downstream >> target is an embedded real-time application. He develops the code >> in a (physics based) simulation of the target environment. For >> example, he develops a a fuel-injection algorithm for an automobile >> engine. Early in the project the embedded real-time group wants an >> estimate of the CPU utilization of his algorithm. The algorithm is >> difficult to run without the context of the enviroment simulation, >> so he has trouble answering this question. Typically, he can only >> make crude estimates. Enter valgrind/xprof. This tool would allow >> the user to quickly provide a better CPU loading estimate within >> his simulation environment by providing cycle count estimates of >> specified regions of code. We are not after exact clock counts, but >> something better than crude flop estimates. >> >> >> >> ------------------------------------------------------------------------------ >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >> endpoint security space. For insight on selecting the right partner to >> tackle endpoint security challenges, access the full report. >> http://p.sf.net/sfu/symantec-dev2dev >> >> >> >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |