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
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
From: Tom H. <th...@cy...> - 2010-01-16 03:49:51
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-16 03:05:03 GMT Ended at 2010-01-16 03:49:32 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-16 03:36:11
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-16 03:10:04 GMT Ended at 2010-01-16 03:35:57 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: <sv...@va...> - 2010-01-15 10:58:07
|
Author: sewardj
Date: 2010-01-15 10:57:57 +0000 (Fri, 15 Jan 2010)
New Revision: 11026
Log:
Add command line flag --vex-guest-chase-cond=no|yes [no] to control
whether front ends should speculatively chase through conditional
branches. Disabled by default.
Modified:
trunk/coregrind/m_main.c
trunk/none/tests/cmdline2.stdout.exp
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2010-01-11 13:02:19 UTC (rev 11025)
+++ trunk/coregrind/m_main.c 2010-01-15 10:57:57 UTC (rev 11026)
@@ -201,6 +201,7 @@
" --vex-iropt-unroll-thresh=<0..400> [120]\n"
" --vex-guest-max-insns=<1..100> [50]\n"
" --vex-guest-chase-thresh=<0..99> [10]\n"
+" --vex-guest-chase-cond=no|yes [no]\n"
" --trace-flags and --profile-flags values (omit the middle space):\n"
" 1000 0000 show conversion into IR\n"
" 0100 0000 show after initial opt\n"
@@ -506,6 +507,8 @@
VG_(clo_vex_control).guest_max_insns, 1, 100) {}
else if VG_BINT_CLO(arg, "--vex-guest-chase-thresh",
VG_(clo_vex_control).guest_chase_thresh, 0, 99) {}
+ else if VG_BOOL_CLO(arg, "--vex-guest-chase-cond",
+ VG_(clo_vex_control).guest_chase_cond) {}
else if VG_INT_CLO(arg, "--log-fd", tmp_log_fd) {
log_to = VgLogTo_Fd;
Modified: trunk/none/tests/cmdline2.stdout.exp
===================================================================
--- trunk/none/tests/cmdline2.stdout.exp 2010-01-11 13:02:19 UTC (rev 11025)
+++ trunk/none/tests/cmdline2.stdout.exp 2010-01-15 10:57:57 UTC (rev 11026)
@@ -90,6 +90,7 @@
--vex-iropt-unroll-thresh=<0..400> [120]
--vex-guest-max-insns=<1..100> [50]
--vex-guest-chase-thresh=<0..99> [10]
+ --vex-guest-chase-cond=no|yes [no]
--trace-flags and --profile-flags values (omit the middle space):
1000 0000 show conversion into IR
0100 0000 show after initial opt
|
|
From: <sv...@va...> - 2010-01-15 10:53:30
|
Author: sewardj
Date: 2010-01-15 10:53:21 +0000 (Fri, 15 Jan 2010)
New Revision: 1957
Log:
Add logic to allow front ends to speculatively continue adding guest
instructions into IRSBs (superblocks) after conditional branches.
Currently only the x86 and amd64 front ends support this. The
assumption is that backwards conditional branches are taken and
forwards conditional branches are not taken, which is generally
regarded as plausible and is particularly effective with code compiled
by gcc at -O2, -O3 or -O -freorder-blocks (-freorder-blocks is enabled
by default at -O2 and above).
Is disabled by default. Has been seen to provide notable speedups
(eg, --tool=none for perf/bz2), and reduces the number of
block-to-block transitions dramatically, by up to half, but usually
makes programs run more slowly. Increases the amount of generated
code by at least 15%-20% and so is a net liability in terms of icache
misses and JIT time.
Modified:
trunk/priv/guest_amd64_defs.h
trunk/priv/guest_amd64_toIR.c
trunk/priv/guest_arm_defs.h
trunk/priv/guest_arm_toIR.c
trunk/priv/guest_generic_bb_to_IR.c
trunk/priv/guest_generic_bb_to_IR.h
trunk/priv/guest_ppc_defs.h
trunk/priv/guest_ppc_toIR.c
trunk/priv/guest_x86_defs.h
trunk/priv/guest_x86_toIR.c
trunk/priv/main_main.c
trunk/pub/libvex.h
Modified: trunk/priv/guest_amd64_defs.h
===================================================================
--- trunk/priv/guest_amd64_defs.h 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_amd64_defs.h 2010-01-15 10:53:21 UTC (rev 1957)
@@ -60,6 +60,7 @@
DisResult disInstr_AMD64 ( IRSB* irbb,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code,
Long delta,
Modified: trunk/priv/guest_amd64_toIR.c
===================================================================
--- trunk/priv/guest_amd64_toIR.c 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_amd64_toIR.c 2010-01-15 10:53:21 UTC (rev 1957)
@@ -8828,6 +8828,7 @@
/*OUT*/Bool* expect_CAS,
Bool put_IP,
Bool (*resteerOkFn) ( /*opaque*/void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
Long delta64,
VexArchInfo* archinfo,
@@ -13726,7 +13727,7 @@
make_redzone_AbiHint(vbi, t1, t2/*nia*/, "call-d32");
if (resteerOkFn( callback_opaque, (Addr64)d64) ) {
/* follow into the call target. */
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = d64;
} else {
jmp_lit(Ijk_Call,d64);
@@ -13956,7 +13957,7 @@
d64 = (guest_RIP_bbstart+delta+1) + getSDisp8(delta);
delta++;
if (resteerOkFn(callback_opaque,d64)) {
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = d64;
} else {
jmp_lit(Ijk_Boring,d64);
@@ -13972,7 +13973,7 @@
d64 = (guest_RIP_bbstart+delta+sz) + getSDisp(sz,delta);
delta += sz;
if (resteerOkFn(callback_opaque,d64)) {
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = d64;
} else {
jmp_lit(Ijk_Boring,d64);
@@ -13997,15 +13998,58 @@
case 0x7D: /* JGEb/JNLb (jump greater or equal) */
case 0x7E: /* JLEb/JNGb (jump less or equal) */
case 0x7F: /* JGb/JNLEb (jump greater) */
+ { Long jmpDelta;
+ HChar* comment = "";
if (haveF2orF3(pfx)) goto decode_failure;
- d64 = (guest_RIP_bbstart+delta+1) + getSDisp8(delta);
+ jmpDelta = getSDisp8(delta);
+ vassert(-128 <= jmpDelta && jmpDelta < 128);
+ d64 = (guest_RIP_bbstart+delta+1) + jmpDelta;
delta++;
- jcc_01( (AMD64Condcode)(opc - 0x70),
- guest_RIP_bbstart+delta,
- d64 );
- dres.whatNext = Dis_StopHere;
- DIP("j%s-8 0x%llx\n", name_AMD64Condcode(opc - 0x70), d64);
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta < 0
+ && resteerOkFn( callback_opaque, d64) ) {
+ /* Speculation: assume this backward branch is taken. So we
+ need to emit a side-exit to the insn following this one,
+ on the negation of the condition, and continue at the
+ branch target address (d64). */
+ stmt( IRStmt_Exit(
+ mk_amd64g_calculate_condition(
+ (AMD64Condcode)(1 ^ (opc - 0x70))),
+ Ijk_Boring,
+ IRConst_U64(guest_RIP_bbstart+delta) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = d64;
+ comment = "(assumed taken)";
+ }
+ else
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta >= 0
+ && resteerOkFn( callback_opaque, guest_RIP_bbstart+delta ) ) {
+ /* Speculation: assume this forward branch is not taken. So
+ we need to emit a side-exit to d64 (the dest) and continue
+ disassembling at the insn immediately following this
+ one. */
+ stmt( IRStmt_Exit(
+ mk_amd64g_calculate_condition((AMD64Condcode)(opc - 0x70)),
+ Ijk_Boring,
+ IRConst_U64(d64) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = guest_RIP_bbstart+delta;
+ comment = "(assumed not taken)";
+ }
+ else {
+ /* Conservative default translation - end the block at this
+ point. */
+ jcc_01( (AMD64Condcode)(opc - 0x70),
+ guest_RIP_bbstart+delta,
+ d64 );
+ dres.whatNext = Dis_StopHere;
+ }
+ DIP("j%s-8 0x%llx %s\n", name_AMD64Condcode(opc - 0x70), d64, comment);
break;
+ }
case 0xE3:
/* JRCXZ or JECXZ, depending address size override. */
@@ -15791,15 +15835,57 @@
case 0x8D: /* JGEb/JNLb (jump greater or equal) */
case 0x8E: /* JLEb/JNGb (jump less or equal) */
case 0x8F: /* JGb/JNLEb (jump greater) */
+ { Long jmpDelta;
+ HChar* comment = "";
if (haveF2orF3(pfx)) goto decode_failure;
- d64 = (guest_RIP_bbstart+delta+4) + getSDisp32(delta);
+ jmpDelta = getSDisp32(delta);
+ d64 = (guest_RIP_bbstart+delta+4) + jmpDelta;
delta += 4;
- jcc_01( (AMD64Condcode)(opc - 0x80),
- guest_RIP_bbstart+delta,
- d64 );
- dres.whatNext = Dis_StopHere;
- DIP("j%s-32 0x%llx\n", name_AMD64Condcode(opc - 0x80), d64);
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta < 0
+ && resteerOkFn( callback_opaque, d64) ) {
+ /* Speculation: assume this backward branch is taken. So
+ we need to emit a side-exit to the insn following this
+ one, on the negation of the condition, and continue at
+ the branch target address (d64). */
+ stmt( IRStmt_Exit(
+ mk_amd64g_calculate_condition(
+ (AMD64Condcode)(1 ^ (opc - 0x80))),
+ Ijk_Boring,
+ IRConst_U64(guest_RIP_bbstart+delta) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = d64;
+ comment = "(assumed taken)";
+ }
+ else
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta >= 0
+ && resteerOkFn( callback_opaque, guest_RIP_bbstart+delta ) ) {
+ /* Speculation: assume this forward branch is not taken.
+ So we need to emit a side-exit to d64 (the dest) and
+ continue disassembling at the insn immediately
+ following this one. */
+ stmt( IRStmt_Exit(
+ mk_amd64g_calculate_condition((AMD64Condcode)(opc - 0x80)),
+ Ijk_Boring,
+ IRConst_U64(d64) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = guest_RIP_bbstart+delta;
+ comment = "(assumed not taken)";
+ }
+ else {
+ /* Conservative default translation - end the block at
+ this point. */
+ jcc_01( (AMD64Condcode)(opc - 0x80),
+ guest_RIP_bbstart+delta,
+ d64 );
+ dres.whatNext = Dis_StopHere;
+ }
+ DIP("j%s-32 0x%llx %s\n", name_AMD64Condcode(opc - 0x80), d64, comment);
break;
+ }
/* =-=-=-=-=-=-=-=-=- PREFETCH =-=-=-=-=-=-=-=-=-= */
case 0x0D: /* 0F 0D /0 -- prefetch mem8 */
@@ -16112,6 +16198,7 @@
DisResult disInstr_AMD64 ( IRSB* irsb_IN,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code_IN,
Long delta,
@@ -16140,6 +16227,7 @@
x1 = irsb_IN->stmts_used;
expect_CAS = False;
dres = disInstr_AMD64_WRK ( &expect_CAS, put_IP, resteerOkFn,
+ resteerCisOk,
callback_opaque,
delta, archinfo, abiinfo );
x2 = irsb_IN->stmts_used;
@@ -16172,6 +16260,7 @@
to generate a useful error message; then assert. */
vex_traceflags |= VEX_TRACE_FE;
dres = disInstr_AMD64_WRK ( &expect_CAS, put_IP, resteerOkFn,
+ resteerCisOk,
callback_opaque,
delta, archinfo, abiinfo );
for (i = x1; i < x2; i++) {
Modified: trunk/priv/guest_arm_defs.h
===================================================================
--- trunk/priv/guest_arm_defs.h 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_arm_defs.h 2010-01-15 10:53:21 UTC (rev 1957)
@@ -55,6 +55,7 @@
DisResult disInstr_ARM ( IRSB* irbb,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code,
Long delta,
Modified: trunk/priv/guest_arm_toIR.c
===================================================================
--- trunk/priv/guest_arm_toIR.c 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_arm_toIR.c 2010-01-15 10:53:21 UTC (rev 1957)
@@ -2642,7 +2642,7 @@
continue tracing at the destination. */
if (resteerOkFn( callback_opaque, (Addr64)dst )) {
/* yes */
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = (Addr64)dst;
} else {
/* no; terminate the SB at this point. */
@@ -4756,6 +4756,7 @@
DisResult disInstr_ARM ( IRSB* irsb_IN,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code_IN,
Long delta,
Modified: trunk/priv/guest_generic_bb_to_IR.c
===================================================================
--- trunk/priv/guest_generic_bb_to_IR.c 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_generic_bb_to_IR.c 2010-01-15 10:53:21 UTC (rev 1957)
@@ -121,6 +121,7 @@
IRSB* irsb;
Addr64 guest_IP_curr_instr;
IRConst* guest_IP_bbstart_IRConst = NULL;
+ Int n_cond_resteers_allowed = 2;
Bool (*resteerOKfn)(void*,Addr64) = NULL;
@@ -209,6 +210,15 @@
resteerOKfn
= resteerOK ? chase_into_ok : const_False;
+ /* n_cond_resteers_allowed keeps track of whether we're still
+ allowing dis_instr_fn to chase conditional branches. It
+ starts (at 2) and gets decremented each time dis_instr_fn
+ tells us it has chased a conditional branch. We then
+ decrement it, and use it to tell later calls to dis_instr_fn
+ whether or not it is allowed to chase conditional
+ branches. */
+ vassert(n_cond_resteers_allowed >= 0 && n_cond_resteers_allowed <= 2);
+
/* This is the IP of the instruction we're just about to deal
with. */
guest_IP_curr_instr = guest_IP_bbstart + delta;
@@ -231,6 +241,7 @@
dres = dis_instr_fn ( irsb,
need_to_put_IP,
resteerOKfn,
+ toBool(n_cond_resteers_allowed > 0),
callback_opaque,
guest_code,
delta,
@@ -243,10 +254,17 @@
/* stay sane ... */
vassert(dres.whatNext == Dis_StopHere
|| dres.whatNext == Dis_Continue
- || dres.whatNext == Dis_Resteer);
+ || dres.whatNext == Dis_ResteerU
+ || dres.whatNext == Dis_ResteerC);
+ /* ... disassembled insn length is sane ... */
vassert(dres.len >= 0 && dres.len <= 20);
- if (dres.whatNext != Dis_Resteer)
+ /* ... continueAt is zero if no resteer requested ... */
+ if (dres.whatNext != Dis_ResteerU && dres.whatNext != Dis_ResteerC)
vassert(dres.continueAt == 0);
+ /* ... if we disallowed conditional resteers, check that one
+ didn't actually happen anyway ... */
+ if (n_cond_resteers_allowed == 0)
+ vassert(dres.whatNext != Dis_ResteerC);
/* Fill in the insn-mark length field. */
vassert(first_stmt_idx >= 0 && first_stmt_idx < irsb->stmts_used);
@@ -313,10 +331,15 @@
case Dis_StopHere:
vassert(irsb->next != NULL);
goto done;
- case Dis_Resteer:
+ case Dis_ResteerU:
+ case Dis_ResteerC:
/* Check that we actually allowed a resteer .. */
vassert(resteerOK);
vassert(irsb->next == NULL);
+ if (dres.whatNext == Dis_ResteerC) {
+ vassert(n_cond_resteers_allowed > 0);
+ n_cond_resteers_allowed--;
+ }
/* figure out a new delta to continue at. */
vassert(resteerOKfn(callback_opaque,dres.continueAt));
delta = dres.continueAt - guest_IP_bbstart;
Modified: trunk/priv/guest_generic_bb_to_IR.h
===================================================================
--- trunk/priv/guest_generic_bb_to_IR.h 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_generic_bb_to_IR.h 2010-01-15 10:53:21 UTC (rev 1957)
@@ -79,9 +79,13 @@
/* What happens next?
Dis_StopHere: this insn terminates the BB; we must stop.
Dis_Continue: we can optionally continue into the next insn
- Dis_Resteer: followed a branch; continue at the spec'd addr
+ Dis_ResteerU: followed an unconditional branch; continue at
+ 'continueAt'
+ Dis_ResteerC: (speculatively, of course) followed a
+ conditional branch; continue at 'continueAt'
*/
- enum { Dis_StopHere, Dis_Continue, Dis_Resteer } whatNext;
+ enum { Dis_StopHere, Dis_Continue,
+ Dis_ResteerU, Dis_ResteerC } whatNext;
/* For Dis_Resteer, this is the guest address we should continue
at. Otherwise ignored (should be zero). */
@@ -123,9 +127,16 @@
or not? */
/*IN*/ Bool put_IP,
- /* Return True iff resteering to the given addr is allowed */
+ /* Return True iff resteering to the given addr is allowed (for
+ branches/calls to destinations that are known at JIT-time) */
/*IN*/ Bool (*resteerOkFn) ( /*opaque*/void*, Addr64 ),
+ /* Should we speculatively resteer across conditional branches?
+ (Experimental and not enabled by default). The strategy is
+ to assume that backward branches are taken and forward
+ branches are not taken. */
+ /*IN*/ Bool resteerCisOk,
+
/* Vex-opaque data passed to all caller (valgrind) supplied
callbacks. */
/*IN*/ void* callback_opaque,
Modified: trunk/priv/guest_ppc_defs.h
===================================================================
--- trunk/priv/guest_ppc_defs.h 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_ppc_defs.h 2010-01-15 10:53:21 UTC (rev 1957)
@@ -61,6 +61,7 @@
DisResult disInstr_PPC ( IRSB* irbb,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code,
Long delta,
Modified: trunk/priv/guest_ppc_toIR.c
===================================================================
--- trunk/priv/guest_ppc_toIR.c 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_ppc_toIR.c 2010-01-15 10:53:21 UTC (rev 1957)
@@ -4324,7 +4324,7 @@
}
if (resteerOkFn( callback_opaque, tgt )) {
- dres->whatNext = Dis_Resteer;
+ dres->whatNext = Dis_ResteerU;
dres->continueAt = tgt;
} else {
irsb->jumpkind = flag_LK ? Ijk_Call : Ijk_Boring;
@@ -8951,6 +8951,7 @@
DisResult disInstr_PPC_WRK (
Bool put_IP,
Bool (*resteerOkFn) ( /*opaque*/void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
Long delta64,
VexArchInfo* archinfo,
@@ -9749,6 +9750,7 @@
DisResult disInstr_PPC ( IRSB* irsb_IN,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code_IN,
Long delta,
@@ -9790,7 +9792,8 @@
guest_CIA_curr_instr = mkSzAddr(ty, guest_IP);
guest_CIA_bbstart = mkSzAddr(ty, guest_IP - delta);
- dres = disInstr_PPC_WRK ( put_IP, resteerOkFn, callback_opaque,
+ dres = disInstr_PPC_WRK ( put_IP,
+ resteerOkFn, resteerCisOk, callback_opaque,
delta, archinfo, abiinfo );
return dres;
Modified: trunk/priv/guest_x86_defs.h
===================================================================
--- trunk/priv/guest_x86_defs.h 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_x86_defs.h 2010-01-15 10:53:21 UTC (rev 1957)
@@ -60,6 +60,7 @@
DisResult disInstr_X86 ( IRSB* irbb,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code,
Long delta,
Modified: trunk/priv/guest_x86_toIR.c
===================================================================
--- trunk/priv/guest_x86_toIR.c 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/guest_x86_toIR.c 2010-01-15 10:53:21 UTC (rev 1957)
@@ -7805,6 +7805,7 @@
/*OUT*/Bool* expect_CAS,
Bool put_IP,
Bool (*resteerOkFn) ( /*opaque*/void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
Long delta64,
VexArchInfo* archinfo
@@ -12599,7 +12600,7 @@
storeLE( mkexpr(t1), mkU32(guest_EIP_bbstart+delta));
if (resteerOkFn( callback_opaque, (Addr64)(Addr32)d32 )) {
/* follow into the call target. */
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = (Addr64)(Addr32)d32;
} else {
jmp_lit(Ijk_Call,d32);
@@ -12885,7 +12886,7 @@
d32 = (((Addr32)guest_EIP_bbstart)+delta+1) + getSDisp8(delta);
delta++;
if (resteerOkFn( callback_opaque, (Addr64)(Addr32)d32) ) {
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = (Addr64)(Addr32)d32;
} else {
jmp_lit(Ijk_Boring,d32);
@@ -12899,7 +12900,7 @@
d32 = (((Addr32)guest_EIP_bbstart)+delta+sz) + getSDisp(sz,delta);
delta += sz;
if (resteerOkFn( callback_opaque, (Addr64)(Addr32)d32) ) {
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerU;
dres.continueAt = (Addr64)(Addr32)d32;
} else {
jmp_lit(Ijk_Boring,d32);
@@ -12924,28 +12925,56 @@
case 0x7D: /* JGEb/JNLb (jump greater or equal) */
case 0x7E: /* JLEb/JNGb (jump less or equal) */
case 0x7F: /* JGb/JNLEb (jump greater) */
- d32 = (((Addr32)guest_EIP_bbstart)+delta+1) + getSDisp8(delta);
+ { Int jmpDelta;
+ HChar* comment = "";
+ jmpDelta = (Int)getSDisp8(delta);
+ vassert(-128 <= jmpDelta && jmpDelta < 128);
+ d32 = (((Addr32)guest_EIP_bbstart)+delta+1) + jmpDelta;
delta++;
- if (0 && resteerOkFn( callback_opaque, (Addr64)(Addr32)d32) ) {
- /* Unused experimental hack: speculatively follow one arm
- of a conditional branch. */
- /* Assume the branch is taken. So we need to emit a
- side-exit to the insn following this one, on the negation
- of the condition, and continue at the branch target
- address (d32). */
- if (0) vex_printf("resteer\n");
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta < 0
+ && resteerOkFn( callback_opaque, (Addr64)(Addr32)d32) ) {
+ /* Speculation: assume this backward branch is taken. So we
+ need to emit a side-exit to the insn following this one,
+ on the negation of the condition, and continue at the
+ branch target address (d32). */
stmt( IRStmt_Exit(
mk_x86g_calculate_condition((X86Condcode)(1 ^ (opc - 0x70))),
Ijk_Boring,
IRConst_U32(guest_EIP_bbstart+delta) ) );
- dres.whatNext = Dis_Resteer;
+ dres.whatNext = Dis_ResteerC;
dres.continueAt = (Addr64)(Addr32)d32;
- } else {
- jcc_01((X86Condcode)(opc - 0x70), (Addr32)(guest_EIP_bbstart+delta), d32);
+ comment = "(assumed taken)";
+ }
+ else
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta >= 0
+ && resteerOkFn( callback_opaque,
+ (Addr64)(Addr32)(guest_EIP_bbstart+delta)) ) {
+ /* Speculation: assume this forward branch is not taken. So
+ we need to emit a side-exit to d32 (the dest) and continue
+ disassembling at the insn immediately following this
+ one. */
+ stmt( IRStmt_Exit(
+ mk_x86g_calculate_condition((X86Condcode)(opc - 0x70)),
+ Ijk_Boring,
+ IRConst_U32(d32) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = (Addr64)(Addr32)(guest_EIP_bbstart+delta);
+ comment = "(assumed not taken)";
+ }
+ else {
+ /* Conservative default translation - end the block at this
+ point. */
+ jcc_01( (X86Condcode)(opc - 0x70),
+ (Addr32)(guest_EIP_bbstart+delta), d32);
dres.whatNext = Dis_StopHere;
}
- DIP("j%s-8 0x%x\n", name_X86Condcode(opc - 0x70), d32);
+ DIP("j%s-8 0x%x %s\n", name_X86Condcode(opc - 0x70), d32, comment);
break;
+ }
case 0xE3: /* JECXZ (for JCXZ see above) */
if (sz != 4) goto decode_failure;
@@ -14448,14 +14477,55 @@
case 0x8D: /* JGEb/JNLb (jump greater or equal) */
case 0x8E: /* JLEb/JNGb (jump less or equal) */
case 0x8F: /* JGb/JNLEb (jump greater) */
- d32 = (((Addr32)guest_EIP_bbstart)+delta+4) + getUDisp32(delta);
+ { Int jmpDelta;
+ HChar* comment = "";
+ jmpDelta = (Int)getUDisp32(delta);
+ d32 = (((Addr32)guest_EIP_bbstart)+delta+4) + jmpDelta;
delta += 4;
- jcc_01( (X86Condcode)(opc - 0x80),
- (Addr32)(guest_EIP_bbstart+delta),
- d32 );
- dres.whatNext = Dis_StopHere;
- DIP("j%s-32 0x%x\n", name_X86Condcode(opc - 0x80), d32);
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta < 0
+ && resteerOkFn( callback_opaque, (Addr64)(Addr32)d32) ) {
+ /* Speculation: assume this backward branch is taken. So
+ we need to emit a side-exit to the insn following this
+ one, on the negation of the condition, and continue at
+ the branch target address (d32). */
+ stmt( IRStmt_Exit(
+ mk_x86g_calculate_condition((X86Condcode)(1 ^ (opc - 0x80))),
+ Ijk_Boring,
+ IRConst_U32(guest_EIP_bbstart+delta) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = (Addr64)(Addr32)d32;
+ comment = "(assumed taken)";
+ }
+ else
+ if (resteerCisOk
+ && vex_control.guest_chase_cond
+ && jmpDelta >= 0
+ && resteerOkFn( callback_opaque,
+ (Addr64)(Addr32)(guest_EIP_bbstart+delta)) ) {
+ /* Speculation: assume this forward branch is not taken.
+ So we need to emit a side-exit to d32 (the dest) and
+ continue disassembling at the insn immediately
+ following this one. */
+ stmt( IRStmt_Exit(
+ mk_x86g_calculate_condition((X86Condcode)(opc - 0x80)),
+ Ijk_Boring,
+ IRConst_U32(d32) ) );
+ dres.whatNext = Dis_ResteerC;
+ dres.continueAt = (Addr64)(Addr32)(guest_EIP_bbstart+delta);
+ comment = "(assumed not taken)";
+ }
+ else {
+ /* Conservative default translation - end the block at
+ this point. */
+ jcc_01( (X86Condcode)(opc - 0x80),
+ (Addr32)(guest_EIP_bbstart+delta), d32);
+ dres.whatNext = Dis_StopHere;
+ }
+ DIP("j%s-32 0x%x %s\n", name_X86Condcode(opc - 0x80), d32, comment);
break;
+ }
/* =-=-=-=-=-=-=-=-=- RDTSC -=-=-=-=-=-=-=-=-=-=-= */
case 0x31: { /* RDTSC */
@@ -14752,6 +14822,7 @@
DisResult disInstr_X86 ( IRSB* irsb_IN,
Bool put_IP,
Bool (*resteerOkFn) ( void*, Addr64 ),
+ Bool resteerCisOk,
void* callback_opaque,
UChar* guest_code_IN,
Long delta,
@@ -14776,6 +14847,7 @@
x1 = irsb_IN->stmts_used;
expect_CAS = False;
dres = disInstr_X86_WRK ( &expect_CAS, put_IP, resteerOkFn,
+ resteerCisOk,
callback_opaque, delta, archinfo );
x2 = irsb_IN->stmts_used;
vassert(x2 >= x1);
@@ -14794,6 +14866,7 @@
to generate a useful error message; then assert. */
vex_traceflags |= VEX_TRACE_FE;
dres = disInstr_X86_WRK ( &expect_CAS, put_IP, resteerOkFn,
+ resteerCisOk,
callback_opaque, delta, archinfo );
for (i = x1; i < x2; i++) {
vex_printf("\t\t");
Modified: trunk/priv/main_main.c
===================================================================
--- trunk/priv/main_main.c 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/priv/main_main.c 2010-01-15 10:53:21 UTC (rev 1957)
@@ -89,6 +89,7 @@
vcon->iropt_unroll_thresh = 120;
vcon->guest_max_insns = 60;
vcon->guest_chase_thresh = 10;
+ vcon->guest_chase_cond = False;
}
@@ -128,6 +129,8 @@
vassert(vcon->guest_max_insns <= 100);
vassert(vcon->guest_chase_thresh >= 0);
vassert(vcon->guest_chase_thresh < vcon->guest_max_insns);
+ vassert(vcon->guest_chase_cond == True
+ || vcon->guest_chase_cond == False);
/* Check that Vex has been built with sizes of basic types as
stated in priv/libvex_basictypes.h. Failure of any of these is
Modified: trunk/pub/libvex.h
===================================================================
--- trunk/pub/libvex.h 2010-01-15 09:54:55 UTC (rev 1956)
+++ trunk/pub/libvex.h 2010-01-15 10:53:21 UTC (rev 1957)
@@ -265,6 +265,9 @@
far, the front end(s) will attempt to chase into its
successor. A setting of zero disables chasing. */
Int guest_chase_thresh;
+ /* EXPERIMENTAL: chase across conditional branches? Not all
+ front ends honour this. Default: NO. */
+ Bool guest_chase_cond;
}
VexControl;
|
|
From: <sv...@va...> - 2010-01-15 09:55:05
|
Author: sewardj
Date: 2010-01-15 09:54:55 +0000 (Fri, 15 Jan 2010)
New Revision: 1956
Log:
amd64: add a couple more spec cases: NLE after SUBL, and NZ after LOGICB.
x86: add commented out (ATC) spec case for C flag after SMULL.
Modified:
trunk/priv/guest_amd64_helpers.c
trunk/priv/guest_x86_helpers.c
Modified: trunk/priv/guest_amd64_helpers.c
===================================================================
--- trunk/priv/guest_amd64_helpers.c 2010-01-11 10:46:18 UTC (rev 1955)
+++ trunk/priv/guest_amd64_helpers.c 2010-01-15 09:54:55 UTC (rev 1956)
@@ -995,7 +995,18 @@
binop(Iop_Shl64,cc_dep2,mkU8(32))));
}
+ if (isU64(cc_op, AMD64G_CC_OP_SUBL) && isU64(cond, AMD64CondNLE)) {
+ /* long sub/cmp, then NLE (signed greater than)
+ --> test !(dst <=s src)
+ --> test (dst >s src)
+ --> test (src <s dst) */
+ return unop(Iop_1Uto64,
+ binop(Iop_CmpLT64S,
+ binop(Iop_Shl64,cc_dep2,mkU8(32)),
+ binop(Iop_Shl64,cc_dep1,mkU8(32))));
+ }
+
if (isU64(cc_op, AMD64G_CC_OP_SUBL) && isU64(cond, AMD64CondBE)) {
/* long sub/cmp, then BE (unsigned less than or equal)
--> test dst <=u src */
@@ -1155,6 +1166,12 @@
binop(Iop_CmpEQ64, binop(Iop_And64,cc_dep1,mkU64(255)),
mkU64(0)));
}
+ if (isU64(cc_op, AMD64G_CC_OP_LOGICB) && isU64(cond, AMD64CondNZ)) {
+ /* byte and/or/xor, then NZ --> test dst!=0 */
+ return unop(Iop_1Uto64,
+ binop(Iop_CmpNE64, binop(Iop_And64,cc_dep1,mkU64(255)),
+ mkU64(0)));
+ }
if (isU64(cc_op, AMD64G_CC_OP_LOGICB) && isU64(cond, AMD64CondS)) {
/* this is an idiom gcc sometimes uses to find out if the top
Modified: trunk/priv/guest_x86_helpers.c
===================================================================
--- trunk/priv/guest_x86_helpers.c 2010-01-11 10:46:18 UTC (rev 1955)
+++ trunk/priv/guest_x86_helpers.c 2010-01-15 09:54:55 UTC (rev 1956)
@@ -1272,6 +1272,22 @@
binop(Iop_Add32, cc_dep1, cc_dep2),
cc_dep1));
}
+ // ATC, requires verification, no test case known
+ //if (isU32(cc_op, X86G_CC_OP_SMULL)) {
+ // /* C after signed widening multiply denotes the case where
+ // the top half of the result isn't simply the sign extension
+ // of the bottom half (iow the result doesn't fit completely
+ // in the bottom half). Hence:
+ // C = hi-half(dep1 x dep2) != lo-half(dep1 x dep2) >>s 31
+ // where 'x' denotes signed widening multiply.*/
+ // return
+ // unop(Iop_1Uto32,
+ // binop(Iop_CmpNE32,
+ // unop(Iop_64HIto32,
+ // binop(Iop_MullS32, cc_dep1, cc_dep2)),
+ // binop(Iop_Sar32,
+ // binop(Iop_Mul32, cc_dep1, cc_dep2), mkU8(31)) ));
+ //}
# if 0
if (cc_op->tag == Iex_Const) {
vex_printf("CFLAG "); ppIRExpr(cc_op); vex_printf("\n");
|
|
From: Julian S. <js...@ac...> - 2010-01-13 21:03:18
|
> Any idea how to attack the problem? > Any workaround? Don't know, sorry. Obviously if you can reduce it to a test case that is small enough to be debuggable, that would be a big help. J |
|
From: Konstantin S. <kon...@gm...> - 2010-01-13 10:21:54
|
Hi, Memcheck hangs at the very end of some of our programs with ~5% probability. I tried running with --trace-signals=yes --trace-syscalls=yes --time-stamp=yes and here is what I've got: When the program finishes successfully, I see 00:00:00:23.549 -1351-- sigvgkill for lwp 31360 tid 5 00:00:00:23.549 31351-- sigvgkill for lwp 31363 tid 7 00:00:00:23.549 -1351-- sigvgkill for lwp 31360 tid 5 00:00:00:23.549 -1351-- sigvgkill for lwp 31360 tid 5 --> [pre-success] Success(0x0:0x0) --00:00:00:23.551 31351-- Caught __NR_exit; running __libc_freeres() <and the program terminates> When the program hangs, I see --00:00:00:23.987 4983-- sigvgkill for lwp 5193 tid 2 --00:00:00:23.987 4983-- get_thread_out_of_syscall zaps tid 3 lwp 5194 --00:00:00:23.987 4983-- sigvgkill for lwp 5194 tid 3 --00:00:00:23.987 4983-- get_thread_out_of_syscall zaps tid 5 lwp 5196 --00:00:00:23.987 4983-- sigvgkill for lwp 5196 tid 5 --> [pre-success] Success(0x0:0x0) <nothing else is happening, valgrind hangs until it is killed externally by timeout> Which is worse, I can not reproduce this on any machine on which I can attach with gdb... Any idea how to attack the problem? Any workaround? Thanks, --kcc |
|
From: Vince W. <vi...@cs...> - 2010-01-13 02:12:52
|
On Wed, 13 Jan 2010, Danny Robson wrote: > I would be a little concerned about feeding approximate processor > timing values into what I believe is a reasonable precise DRAM timing > model. This is actually the topic of my PhD thesis (defended last month, am finishing up the thesis right now). I look at using DBI tools like Valgrind and Qemu to do architectural simulations, in an attempt to get results faster than "cycle-accurate" simulation with good enough accuracy. It turns out that for a RISC chip, such as MIPS, you can get very good cycle estimations based solely on cache and branch predictor results (even on an out-of-order processor). Unfortunately the results are not as good for x86, and it's even trickier if you are trying to do multi-core. > If you are interested in this level of precision it may be more > appropriate to look at PTLsim[1], which uses a 'cycle-accurate' > processing timing model. It's also at least two orders of magnitude slower, which is why alternate options are usually explored. Vince |
|
From: Danny R. <dr...@cs...> - 2010-01-13 00:59:23
|
On Tue, 12 Jan 2010 13:31:37 +0530 Milind <km...@gm...> wrote: > I have started exploring valgrind recently. I wanted to know if > valgrind core keeps track of the CPU clock ticks. I want to record > memory access pattern of my program. It might help to know more about what you want to accomplish at the end of the day. Do you want to identify regions of suboptimal code, quantify the runtime of some application, experiment with different system parameters? > In that context, I wanted to record the CPU clock tick value at the > time of memory access. I want to feed output of valgrind to DRAMsim > which needs memory addr that is being accessed, access type (read, > write, etc) and the cpu clock time value when the access is being > done. I would be a little concerned about feeding approximate processor timing values into what I believe is a reasonable precise DRAM timing model. If you are interested in this level of precision it may be more appropriate to look at PTLsim[1], which uses a 'cycle-accurate' processing timing model. [1] http://www.ptlsim.org/ -- Danny |
|
From: Milind <km...@gm...> - 2010-01-12 15:44:58
|
On Tue, Jan 12, 2010 at 8:58 PM, Josef Weidendorfer < Jos...@gm...> wrote: > On Tuesday 12 January 2010, Milind wrote: > > > By multiplying the event counts from cachegrind output with penalties > for > > > the > > > different event types, you can come up with clock tick estimations, > yes. > > > > > > > [milind] can you elaborate little more ? :) > > Cachegrind output is aggregated, as it is about profiling. You can get > aggregated figures for estimated time spent in given functions, e.g. by > using > a time penalty of 1 cycle for every executed instruction (this can be done > by > using the Ir event count), e.g. 10 cycles for L1 misses (using I1mr, D1mr, > and D1mw > events), e.g. 200 cycles for L2 misses (using I2mr, D2mr, and D2mw), and so > on > (KCachegrind allows to directly enter custom formulas). > [milind] Correct. I came till this point. I know exactly how many L1 cache misses, L2 cache misses (these are nothing but main memory accesses), number of instructions etc. > > However, the aggregated numbers probably won't help you much. I would > suggest to > [milind] This is true. These are aggregated numbers and are not helping completely. modify cachegrinds source to give you an trace of events, and from this you > can > reconstruct a simulated CPU clock tick counter, by advancing it according > to > events happening. > [milind] Well said again. This is where I am right now. I will have to explore the cachegrind code. May be Lackey may also be of help to some extent. But I doubt if Lackey takes cache hits into account. > > However, this will only work for sequential code. For multithreaded code, > Valgrind serializes threads by executing a fixed number of blocks for > each thread, and then allows for thread switching, leaving the actual > scheduling decision to the OS (I hope I got this right). > [milind] Yes, multithreaded code wont help much. For now I am confining myself to single thread. Really appreciate your thoughts and help. - Milind > > Josef > > > > Thanks, > > - Milind > > > > > > > > Josef > > > > > > > I am sure I wont need full-system simulators > > > > yet. > > > > > > > > Thanks, > > > > - Milind > > > > > > > > On Tue, Jan 12, 2010 at 6:45 PM, Josef Weidendorfer < > > > > Jos...@gm...> wrote: > > > > > > > > > Hi, > > > > > > > > > > On Tuesday 12 January 2010, Milind wrote: > > > > > > I have started exploring valgrind recently. I wanted to know if > > > valgrind > > > > > > core keeps track of the CPU clock ticks. > > > > > > > > > > Which ticks do you mean? Wall clock time makes not much sense, as > this > > > > > would > > > > > include all housekeeping tasks Valgrind is doing, such as > > > instrumentation > > > > > of > > > > > client code. So, there really is no "CPU clock tick" to keep track > of. > > > > > You have to maintain your own tick counter if you want something > like > > > this. > > > > > > > > > > And how you want this counter to advance is totally up to you and > > > depends > > > > > on > > > > > the type of processor model you envision. E.g. you could include a > > > cache > > > > > model, > > > > > a branch predictor, latency/troughput parameters for different > > > instruction > > > > > types and so on, and advance the clock tick counter accordingly. > > > > > Just a note: it probably gets arbitrarily complex to approximate > the > > > tick > > > > > counter > > > > > of a real processor; and this only will work for the user-level > side > > > with > > > > > one > > > > > process. > > > > > > > > > > Perhaps it is better for you to look at cycle-accurate full-system > > > > > simulators? > > > > > > > > > > Josef > > > > > > > > > > > I want to record memory access > > > > > > pattern of my program. In that context, I wanted to record the > CPU > > > clock > > > > > > tick value at the time of memory access. I want to feed output of > > > > > valgrind > > > > > > to DRAMsim which needs memory addr that is being accessed, access > > > type > > > > > > (read, write, etc) and the cpu clock time value when the access > is > > > being > > > > > > done. Any pointers/links will help. > > > > > > > > > > > > Thanks, > > > > > > - Milind > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
From: Milind <km...@gm...> - 2010-01-12 14:37:46
|
Hi Josef, On Tue, Jan 12, 2010 at 7:47 PM, Josef Weidendorfer < Jos...@gm...> wrote: > Hi Milind, > > On Tuesday 12 January 2010, Milind wrote: > > Thanks Josef for the reply. I am referring to CPU clock ticks and not the > > wall clock. > > with "wall clock", I actually meant any time source derived from real time > (including CPU clock ticks of the Valgrind process). > > > Couple of responses that I received also indicate that there is > > no real CPU clock tick simulation. > > How could there be? Valgrind does not enforce any performance model with > given time characteristics on you, and such a thing is not needed by > any Valgrind tool. So, how should it be able to provide you with a > clock tick simulation? > [milind] Ok. Got this now. > > > Let me see if I can cover my requirement > > with the cachegrind output. > > By multiplying the event counts from cachegrind output with penalties for > the > different event types, you can come up with clock tick estimations, yes. > [milind] can you elaborate little more ? :) Thanks, - Milind > > Josef > > > I am sure I wont need full-system simulators > > yet. > > > > Thanks, > > - Milind > > > > On Tue, Jan 12, 2010 at 6:45 PM, Josef Weidendorfer < > > Jos...@gm...> wrote: > > > > > Hi, > > > > > > On Tuesday 12 January 2010, Milind wrote: > > > > I have started exploring valgrind recently. I wanted to know if > valgrind > > > > core keeps track of the CPU clock ticks. > > > > > > Which ticks do you mean? Wall clock time makes not much sense, as this > > > would > > > include all housekeeping tasks Valgrind is doing, such as > instrumentation > > > of > > > client code. So, there really is no "CPU clock tick" to keep track of. > > > You have to maintain your own tick counter if you want something like > this. > > > > > > And how you want this counter to advance is totally up to you and > depends > > > on > > > the type of processor model you envision. E.g. you could include a > cache > > > model, > > > a branch predictor, latency/troughput parameters for different > instruction > > > types and so on, and advance the clock tick counter accordingly. > > > Just a note: it probably gets arbitrarily complex to approximate the > tick > > > counter > > > of a real processor; and this only will work for the user-level side > with > > > one > > > process. > > > > > > Perhaps it is better for you to look at cycle-accurate full-system > > > simulators? > > > > > > Josef > > > > > > > I want to record memory access > > > > pattern of my program. In that context, I wanted to record the CPU > clock > > > > tick value at the time of memory access. I want to feed output of > > > valgrind > > > > to DRAMsim which needs memory addr that is being accessed, access > type > > > > (read, write, etc) and the cpu clock time value when the access is > being > > > > done. Any pointers/links will help. > > > > > > > > Thanks, > > > > - Milind > > > > > > > > > > > > > > > > > > |
|
From: Milind <km...@gm...> - 2010-01-12 13:55:08
|
Thanks Josef for the reply. I am referring to CPU clock ticks and not the wall clock. Couple of responses that I received also indicate that there is no real CPU clock tick simulation. Let me see if I can cover my requirement with the cachegrind output. I am sure I wont need full-system simulators yet. Thanks, - Milind On Tue, Jan 12, 2010 at 6:45 PM, Josef Weidendorfer < Jos...@gm...> wrote: > Hi, > > On Tuesday 12 January 2010, Milind wrote: > > I have started exploring valgrind recently. I wanted to know if valgrind > > core keeps track of the CPU clock ticks. > > Which ticks do you mean? Wall clock time makes not much sense, as this > would > include all housekeeping tasks Valgrind is doing, such as instrumentation > of > client code. So, there really is no "CPU clock tick" to keep track of. > You have to maintain your own tick counter if you want something like this. > > And how you want this counter to advance is totally up to you and depends > on > the type of processor model you envision. E.g. you could include a cache > model, > a branch predictor, latency/troughput parameters for different instruction > types and so on, and advance the clock tick counter accordingly. > Just a note: it probably gets arbitrarily complex to approximate the tick > counter > of a real processor; and this only will work for the user-level side with > one > process. > > Perhaps it is better for you to look at cycle-accurate full-system > simulators? > > Josef > > > I want to record memory access > > pattern of my program. In that context, I wanted to record the CPU clock > > tick value at the time of memory access. I want to feed output of > valgrind > > to DRAMsim which needs memory addr that is being accessed, access type > > (read, write, etc) and the cpu clock time value when the access is being > > done. Any pointers/links will help. > > > > Thanks, > > - Milind > > > > > |
|
From: Bart V. A. <bar...@gm...> - 2010-01-12 08:55:38
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-12 02:27:52 EST Ended at 2010-01-12 03:55:22 EST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 449 tests, 43 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Milind <km...@gm...> - 2010-01-12 08:01:45
|
Hello VG developers, I have started exploring valgrind recently. I wanted to know if valgrind core keeps track of the CPU clock ticks. I want to record memory access pattern of my program. In that context, I wanted to record the CPU clock tick value at the time of memory access. I want to feed output of valgrind to DRAMsim which needs memory addr that is being accessed, access type (read, write, etc) and the cpu clock time value when the access is being done. Any pointers/links will help. Thanks, - Milind |
|
From: Alexander P. <gl...@go...> - 2010-01-12 06:54:20
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-12 09:06:02 MSK Ended at 2010-01-12 09:24:45 MSK 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 == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-01-12 03:49:36
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-12 03:05:04 GMT Ended at 2010-01-12 03:49:17 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-12 03:35:55
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-12 03:10:04 GMT Ended at 2010-01-12 03:35:36 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Maynard J. <may...@us...> - 2010-01-11 22:10:56
|
The attached patch addresses a problem that I reported to this list on Jan 4. Julian suggested the fix, so my patch integrates his suggestion into the failing testcases' source files. Problem description: Upon a call to a function, some architectures store pointers into into registers. Valgrind may consider these registers when determining whether an address is reachable, so we need to zero-out these registers as needed. This patch addresses the problem only for PowerPC, but the implementation for other architectures can be easily added when necessary. Thanks. -Maynard |
|
From: <sv...@va...> - 2010-01-11 13:10:02
|
Author: sewardj
Date: 2010-01-11 13:02:19 +0000 (Mon, 11 Jan 2010)
New Revision: 11025
Log:
Apparently the dynamic linker on ARM-Linux has soname "ld-linux.so.3"
rather than "ld-linux.so.2". No, don't ask me why. Anyway, on
Helgrind, don't instrument code in ld-linux.so.3. This makes Helgrind
pretty much usable on ARM-Linux.
Modified:
trunk/helgrind/hg_main.c
trunk/include/pub_tool_redir.h
Modified: trunk/helgrind/hg_main.c
===================================================================
--- trunk/helgrind/hg_main.c 2010-01-09 11:44:21 UTC (rev 11024)
+++ trunk/helgrind/hg_main.c 2010-01-11 13:02:19 UTC (rev 11025)
@@ -3885,6 +3885,7 @@
if (0) VG_(printf)("%s\n", soname);
# if defined(VGO_linux)
+ if (VG_STREQ(soname, VG_U_LD_LINUX_SO_3)) return True;
if (VG_STREQ(soname, VG_U_LD_LINUX_SO_2)) return True;
if (VG_STREQ(soname, VG_U_LD_LINUX_X86_64_SO_2)) return True;
if (VG_STREQ(soname, VG_U_LD64_SO_1)) return True;
Modified: trunk/include/pub_tool_redir.h
===================================================================
--- trunk/include/pub_tool_redir.h 2010-01-09 11:44:21 UTC (rev 11024)
+++ trunk/include/pub_tool_redir.h 2010-01-11 13:02:19 UTC (rev 11025)
@@ -215,6 +215,9 @@
#if defined(VGO_linux)
+#define VG_Z_LD_LINUX_SO_3 ldZhlinuxZdsoZd3 // ld-linux.so.3
+#define VG_U_LD_LINUX_SO_3 "ld-linux.so.3"
+
#define VG_Z_LD_LINUX_SO_2 ldZhlinuxZdsoZd2 // ld-linux.so.2
#define VG_U_LD_LINUX_SO_2 "ld-linux.so.2"
|
|
From: <sv...@va...> - 2010-01-11 10:46:28
|
Author: sewardj
Date: 2010-01-11 10:46:18 +0000 (Mon, 11 Jan 2010)
New Revision: 1955
Log:
For 32-bit reads of integer guest registers, generate a 64-bit Get
followed by a Iop_64to32 narrowing, rather than doing a 32-bit Get.
This makes the Put-to-Get-forwarding optimisation work seamlessly for
code which does 32-bit register operations (very common), which it
never did before. Also add a folding rule to remove the resulting
32-to-64-to-32 widen-narrow chains.
This reduces the amount of code generated overall about 3%, but gives
a much larger speedup, of about 11% for Memcheck running perf/bz2.c.
Not sure why this is, perhaps due to reducing store bandwidth
requirements in the generated code, or due to avoiding
store-forwarding stalls when writing/reading the guest state.
Modified:
trunk/priv/guest_amd64_toIR.c
trunk/priv/ir_opt.c
Modified: trunk/priv/guest_amd64_toIR.c
===================================================================
--- trunk/priv/guest_amd64_toIR.c 2010-01-09 11:43:21 UTC (rev 1954)
+++ trunk/priv/guest_amd64_toIR.c 2010-01-11 10:46:18 UTC (rev 1955)
@@ -972,7 +972,7 @@
switch (sz) {
case 1: return IRExpr_Get( OFFB_RAX, Ity_I8 );
case 2: return IRExpr_Get( OFFB_RAX, Ity_I16 );
- case 4: return IRExpr_Get( OFFB_RAX, Ity_I32 );
+ case 4: return unop(Iop_64to32, IRExpr_Get( OFFB_RAX, Ity_I64 ));
case 8: return IRExpr_Get( OFFB_RAX, Ity_I64 );
default: vpanic("getIRegRAX(amd64)");
}
@@ -1020,7 +1020,7 @@
switch (sz) {
case 1: return IRExpr_Get( OFFB_RDX, Ity_I8 );
case 2: return IRExpr_Get( OFFB_RDX, Ity_I16 );
- case 4: return IRExpr_Get( OFFB_RDX, Ity_I32 );
+ case 4: return unop(Iop_64to32, IRExpr_Get( OFFB_RDX, Ity_I64 ));
case 8: return IRExpr_Get( OFFB_RDX, Ity_I64 );
default: vpanic("getIRegRDX(amd64)");
}
@@ -1071,8 +1071,9 @@
static IRExpr* getIReg32 ( UInt regno )
{
vassert(!host_is_bigendian);
- return IRExpr_Get( integerGuestReg64Offset(regno),
- Ity_I32 );
+ return unop(Iop_64to32,
+ IRExpr_Get( integerGuestReg64Offset(regno),
+ Ity_I64 ));
}
static void putIReg32 ( UInt regno, IRExpr* e )
@@ -1136,11 +1137,22 @@
vassert(lo3bits < 8);
vassert(IS_VALID_PFX(pfx));
vassert(sz == 8 || sz == 4 || sz == 2 || sz == 1);
- return IRExpr_Get(
- offsetIReg( sz, lo3bits | (getRexB(pfx) << 3),
- toBool(sz==1 && !haveREX(pfx)) ),
- szToITy(sz)
- );
+ if (sz == 4) {
+ sz = 8;
+ return unop(Iop_64to32,
+ IRExpr_Get(
+ offsetIReg( sz, lo3bits | (getRexB(pfx) << 3),
+ toBool(sz==1 && !haveREX(pfx)) ),
+ szToITy(sz)
+ )
+ );
+ } else {
+ return IRExpr_Get(
+ offsetIReg( sz, lo3bits | (getRexB(pfx) << 3),
+ toBool(sz==1 && !haveREX(pfx)) ),
+ szToITy(sz)
+ );
+ }
}
static void putIRegRexB ( Int sz, Prefix pfx, UInt lo3bits, IRExpr* e )
@@ -1206,8 +1218,15 @@
static
IRExpr* getIRegG ( Int sz, Prefix pfx, UChar mod_reg_rm )
{
- return IRExpr_Get( offsetIRegG( sz, pfx, mod_reg_rm ),
- szToITy(sz) );
+ if (sz == 4) {
+ sz = 8;
+ return unop(Iop_64to32,
+ IRExpr_Get( offsetIRegG( sz, pfx, mod_reg_rm ),
+ szToITy(sz) ));
+ } else {
+ return IRExpr_Get( offsetIRegG( sz, pfx, mod_reg_rm ),
+ szToITy(sz) );
+ }
}
static
@@ -1246,8 +1265,15 @@
static
IRExpr* getIRegE ( Int sz, Prefix pfx, UChar mod_reg_rm )
{
- return IRExpr_Get( offsetIRegE( sz, pfx, mod_reg_rm ),
- szToITy(sz) );
+ if (sz == 4) {
+ sz = 8;
+ return unop(Iop_64to32,
+ IRExpr_Get( offsetIRegE( sz, pfx, mod_reg_rm ),
+ szToITy(sz) ));
+ } else {
+ return IRExpr_Get( offsetIRegE( sz, pfx, mod_reg_rm ),
+ szToITy(sz) );
+ }
}
static
Modified: trunk/priv/ir_opt.c
===================================================================
--- trunk/priv/ir_opt.c 2010-01-09 11:43:21 UTC (rev 1954)
+++ trunk/priv/ir_opt.c 2010-01-11 10:46:18 UTC (rev 1955)
@@ -3970,6 +3970,11 @@
if (is_Unop(aa, Iop_CmpwNEZ64))
return IRExpr_Unop( Iop_CmpNEZ64, aa->Iex.Unop.arg );
break;
+ case Iop_64to32:
+ /* 64to32( 32Uto64 ( x )) --> x */
+ if (is_Unop(aa, Iop_32Uto64))
+ return aa->Iex.Unop.arg;
+ break;
case Iop_1Sto32:
/* 1Sto32( CmpNEZ8( 32to8( 1Uto32( CmpNEZ32( x ))))) -> CmpwNEZ32(x) */
@@ -3984,6 +3989,7 @@
}
break;
+
default:
break;
}
|
|
From: Stefan K. <en...@ho...> - 2010-01-10 13:12:17
|
Am 05.01.2010 01:21, schrieb Nicholas Nethercote: > On Mon, Dec 28, 2009 at 10:16 AM, Stefan Kost <en...@ho...> wrote: >> Am 27.12.2009 16:29, schrieb Bart Van Assche: >>> On Sat, Dec 26, 2009 at 5:52 PM, Stefan Kost <en...@ho... >>> <mailto:en...@ho...>> wrote: >>> >>> I am quite interested in a coverage tool that does not need >>> recompilation. There >>> seems to be a patched qemu somewhere, but then I found >>> valgrind-vcov. I had some >>> issue building the branch. >>> >>> That is because at the time a Valgrind branch is created, only Valgrind >>> is branched but not VEX. If you look up the last modification date of >>> the Valgrind code on the Valgrind branch and update the VEX source code >>> to that date, then the build should succeed. >> >> Thanks that helps, would be nice to put this to README_DEVELOPERS. > > VCov is on a branch, I haven't done anything with it for a while and > probably won't any time soon. > > Nick Should I still submit my patch to bugzilla? If vcov is dead I'll use my time on hacking on bcov then (bcov.sf.net) - it an interesting alternative. Stefan |
|
From: Bart V. A. <bar...@gm...> - 2010-01-10 09:10:43
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-10 02:27:39 EST Ended at 2010-01-10 04:10:28 EST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 449 tests, 43 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Alexander P. <gl...@go...> - 2010-01-10 07:53:58
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-10 09:06:02 MSK Ended at 2010-01-10 09:24:48 MSK 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 == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-01-10 03:49:28
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-10 03:05:04 GMT Ended at 2010-01-10 03:49:14 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-10 03:35:43
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-10 03:10:03 GMT Ended at 2010-01-10 03:35:31 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |