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
(2) |
2
(7) |
3
(1) |
4
(9) |
5
|
|
6
(7) |
7
(10) |
8
(23) |
9
(19) |
10
(21) |
11
(14) |
12
(15) |
|
13
(11) |
14
(7) |
15
(20) |
16
(21) |
17
(20) |
18
(20) |
19
(19) |
|
20
(24) |
21
(22) |
22
(19) |
23
(17) |
24
(26) |
25
(15) |
26
(16) |
|
27
(8) |
28
(10) |
29
(24) |
30
(21) |
31
(19) |
|
|
|
From: David B. <dav...@gm...> - 2013-01-06 21:24:10
|
John, That's true for memcheck if interested in memory corruption issues. What about massif? It seems that if we only want memory measurements, wouldn't it be enough to just handle malloc/free/etc.? What if I want to run memcheck just to find memory leaks? Doesn't seem to me that I need actual instrumentation here of all code, no? Even for the complete memcheck functionality, some use cases may live well enough with just instrumenting a part of the program. Say I have a huge program, which contain tons of DLLs, most of them not under my responsibility and/or I can't fix the bugs in them. If I just want to memcheck my DLL, and am willing to live with the assumption that memory my DLL allocates is only read/written by my DLL, it seems reasonable to only translate and handle my DLL, no? On Sun, Jan 6, 2013 at 11:06 PM, John Reiser <jr...@bi...> wrote: > > What I want is basically to instrument only a couple of .so modules, > > leaving anything else unchanged. > > In order to compute correct answers, memcheck must observe > every instruction whose input(s) derive from memory, > or whose output(s) eventually go to memory. > "Partial instrumentation" would be possible only for > a program which directly spews constants. > > -- > > |
|
From: John R. <jr...@bi...> - 2013-01-06 21:05:40
|
> What I want is basically to instrument only a couple of .so modules, > leaving anything else unchanged. In order to compute correct answers, memcheck must observe every instruction whose input(s) derive from memory, or whose output(s) eventually go to memory. "Partial instrumentation" would be possible only for a program which directly spews constants. -- |
|
From: Timur I. <tim...@go...> - 2013-01-06 20:17:26
|
Hi, I'm benchmarking Valgrind (as an instrumentation framework) on large apps and noticed it's sometimes too slow. For example, running DumpRenderTree* takes ~16.5 seconds under an "empty" tool (similar to "none") on my machine. The same binary runs for just 0.3 seconds without Valgrind. This is roughly a 50x slowdown, I'd expect it to be much smaller when doing little to no additional instrumentation. See a tool I've created for my benchmarking attached, it runs the same test in 17 seconds. Flipping "#if 0" -> "#if 1" gives the 16.5 seconds mentioned above. That means, almost all the overhead is inside Valgrind. Is there any way to optimize Valgrind for such usage? What I want is basically to instrument only a couple of .so modules, leaving anything else unchanged. Thanks! * - DumpRenderTree is one of the targets in a Chromium checkout. I've built a Release build of DRT and ran it like this: xvfb-run time ./valgrind-3.8.1/BUILD/bin/valgrind --tool=vgtool ../DumpRenderTree ../hello.html You can find the build instructions here: http://code.google.com/p/chromium/wiki/LinuxBuildInstructions and hello.html is just "<html><body>Hello world!</body></html>". I ran the tests on Intel Xeon E5620, Ubuntu 12.04, gcc 4.6.3. -- Timur Iskhodzhanov, Google Russia |
|
From: Florian K. <br...@ac...> - 2013-01-06 16:50:20
|
Allow the tree builder to move load expressions past statements that modify the guest state, unless the guest state modification requires precise exceptions. This improvement was already suggested in a comment in the code and this patch implements that suggestion. s390 will get more opportunities to use memory-to-memory move insns. regtested on x86-64 and s390 with no new regressions. I'll wait for approval before checking this in. Florian |
|
From: Florian K. <br...@ac...> - 2013-01-06 16:04:09
|
On 01/06/2013 10:48 AM, Julian Seward wrote:
>
>>> One change I am looking at is changing the guard type of Mux0X
>>> from I8 to I1. This makes it consistent with I1 guard types for
>>> Dirty helpers and for Exits.
>>
>> Seconded.
>
> I have this working now for ARM, and, obviously, the generic IR
> stuff has been fixed up too. I can do the front/back end fixes
> for x86/amd64/ppc32/ppc64, and possibly MIPS, but I can't do the
> s390 bits. If I make available a patch containing the above stuff,
> can you do the s390 bits?
Sure, no problem.
>> I'm willing to make the change if you and/or other port maintainers are
>> willing to double-check.
>
> Yes, I'm willing to double-check/review.
OK, let's do it them. Do you want to merge COMEM first ?
How about this (with ITE meaning if-then-else)?
Index: VEX/pub/libvex_ir.h
===================================================================
--- VEX/pub/libvex_ir.h (revision 2627)
+++ VEX/pub/libvex_ir.h (working copy)
@@ -1578,7 +1578,7 @@
Iex_Unop,
Iex_Load,
Iex_Const,
- Iex_Mux0X,
+ Iex_ITE,
Iex_CCall
}
IRExprTag;
@@ -1762,18 +1762,18 @@
IRExpr** args; /* Vector of argument expressions. */
} CCall;
- /* A ternary if-then-else operator. It returns expr0 if cond is
- zero, exprX otherwise. Note that it is STRICT, ie. both
- expr0 and exprX are evaluated in all cases.
+ /* A ternary if-then-else operator. It returns iftrue if cond is
+ zero, iffalse otherwise. Note that it is STRICT, ie. both
+ iftrue and iffalse are evaluated in all cases.
- ppIRExpr output: Mux0X(<cond>,<expr0>,<exprX>),
- eg. Mux0X(t6,t7,t8)
+ ppIRExpr output: ITE(<cond>,<iftrue>,<iffalse>),
+ eg. ITE(t6,t7,t8)
*/
struct {
IRExpr* cond; /* Condition */
- IRExpr* expr0; /* True expression */
- IRExpr* exprX; /* False expression */
- } Mux0X;
+ IRExpr* iftrue; /* True expression */
+ IRExpr* iffalse; /* False expression */
+ } ITE;
} Iex;
};
@@ -1808,7 +1808,7 @@
extern IRExpr* IRExpr_Load ( IREndness end, IRType ty, IRExpr* addr );
extern IRExpr* IRExpr_Const ( IRConst* con );
extern IRExpr* IRExpr_CCall ( IRCallee* cee, IRType retty, IRExpr**
args );
-extern IRExpr* IRExpr_Mux0X ( IRExpr* cond, IRExpr* expr0, IRExpr*
exprX );
+extern IRExpr* IRExpr_ITE ( IRExpr* cond, IRExpr* expr0, IRExpr*
exprX );
/* Deep-copy an IRExpr. */
extern IRExpr* deepCopyIRExpr ( IRExpr* );
|
|
From: Julian S. <js...@ac...> - 2013-01-06 15:48:19
|
> > One change I am looking at is changing the guard type of Mux0X > > from I8 to I1. This makes it consistent with I1 guard types for > > Dirty helpers and for Exits. > > Seconded. I have this working now for ARM, and, obviously, the generic IR stuff has been fixed up too. I can do the front/back end fixes for x86/amd64/ppc32/ppc64, and possibly MIPS, but I can't do the s390 bits. If I make available a patch containing the above stuff, can you do the s390 bits? Unfortunately this is not something that can be committed incrementally without breaking various front/back ends. > I'm willing to make the change if you and/or other port maintainers are > willing to double-check. Yes, I'm willing to double-check/review. J |
|
From: Florian K. <br...@ac...> - 2013-01-06 14:48:22
|
On 01/04/2013 06:21 AM, Julian Seward wrote: > > One change I am looking at is changing the guard type of Mux0X > from I8 to I1. This makes it consistent with I1 guard types for > Dirty helpers and for Exits. Seconded. > Changing the order of the second and third args in Mux0X, so it > matches the familiar C ?-: syntax, and possibly renaming it, > would be a nice thing, but does not change the generated code. > If anyone wants to volunteer to do that (and verify the change is > correct :) please speak up. Yes this would be good to do. I never understood why this IROp was defined this way and I made a few mistakes using it at the time. The change is obviously mechanical. But I would not know how to verify it other than having somebody else proof-read the patch. Passing regtest is too weak a criterion... I'm willing to make the change if you and/or other port maintainers are willing to double-check. Florian |