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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(39) |
2
(29) |
3
(27) |
4
(50) |
5
(37) |
|
6
(14) |
7
(28) |
8
(44) |
9
(38) |
10
(32) |
11
(49) |
12
(51) |
|
13
(37) |
14
(32) |
15
(70) |
16
(50) |
17
(43) |
18
(56) |
19
(23) |
|
20
(22) |
21
(36) |
22
(12) |
23
(22) |
24
(10) |
25
(13) |
26
(21) |
|
27
(17) |
28
(16) |
29
(33) |
30
(14) |
|
|
|
|
From: <sv...@va...> - 2005-11-04 14:43:05
|
Author: tom Date: 2005-11-04 14:25:09 +0000 (Fri, 04 Nov 2005) New Revision: 5000 Log: Add missing tag. Modified: trunk/docs/xml/writing-tools.xml Modified: trunk/docs/xml/writing-tools.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/writing-tools.xml 2005-11-04 14:11:05 UTC (rev 4999) +++ trunk/docs/xml/writing-tools.xml 2005-11-04 14:25:09 UTC (rev 5000) @@ -286,7 +286,7 @@ (<computeroutput>libcoregrind.a</computeroutput>) that valgrind provides as well as the VEX library (<computeroutput>libvex.a</computeroutput>) that also comes with -valgrind and provides the JIT engine. +valgrind and provides the JIT engine.</para> =20 <para>Each tool is linked as a statically linked program and placed in the valgrind library directory from where valgrind will load it |
|
From: <sv...@va...> - 2005-11-04 14:39:09
|
Author: sewardj
Date: 2005-11-04 14:38:48 +0000 (Fri, 04 Nov 2005)
New Revision: 5001
Log:
Also test jecxz.
Modified:
trunk/none/tests/amd64/jrcxz.c
trunk/none/tests/amd64/jrcxz.stdout.exp
Modified: trunk/none/tests/amd64/jrcxz.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/amd64/jrcxz.c 2005-11-04 14:25:09 UTC (rev 5000)
+++ trunk/none/tests/amd64/jrcxz.c 2005-11-04 14:38:48 UTC (rev 5001)
@@ -2,35 +2,68 @@
#include <stdio.h>
=20
typedef unsigned long long int ULong;
+typedef unsigned int UInt;
=20
-ULong arg, res;
+ULong arg64, res64;
=20
-extern void foo ( void );
+extern void foo64 ( void );
asm("\n"
-"foo:\n"
+"foo64:\n"
"\tpushq %rcx\n"
=20
"\tmovq $0, %rax\n"
-"\tmovq arg, %rcx\n"
+"\tmovq arg64, %rcx\n"
=20
-"Lagain:\n"
+"Lagain64:\n"
"\taddq $177, %rax\n"
"\tdecq %rcx\n"
-"\tjrcxz Lout\n"
-"\tjmp Lagain\n"
+"\tjrcxz Lout64\n"
+"\tjmp Lagain64\n"
=20
-"Lout:\n"
-"\tmovq %rax, res\n"
+"Lout64:\n"
+"\tmovq %rax, res64\n"
=20
"\tpopq %rcx\n"
"\tret\n"
);
=20
+
+UInt arg32, res32;
+
+extern void foo32 ( void );
+asm("\n"
+"foo32:\n"
+"\tpushq %rcx\n"
+
+"\tmovq $0, %rax\n"
+"\tmovl arg32, %ecx\n"
+
+"Lagain32:\n"
+"\taddq $177, %rax\n"
+"\tdecl %ecx\n"
+"\tjecxz Lout32\n"
+"\tjmp Lagain32\n"
+
+"Lout32:\n"
+"\tmovl %eax, res32\n"
+
+"\tpopq %rcx\n"
+"\tret\n"
+);
+
+
+
int main ( void )
{
- arg =3D 100;
- res =3D 0;
- foo();
- printf("%lld\n", res);
+ arg64 =3D 100;
+ res64 =3D 0;
+ foo64();
+ printf("%lld\n", res64);
+
+ arg32 =3D 1234;
+ res32 =3D 0;
+ foo32();
+ printf("%d\n", res32);
+
return 0;
}
Modified: trunk/none/tests/amd64/jrcxz.stdout.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/amd64/jrcxz.stdout.exp 2005-11-04 14:25:09 UTC (rev =
5000)
+++ trunk/none/tests/amd64/jrcxz.stdout.exp 2005-11-04 14:38:48 UTC (rev =
5001)
@@ -1 +1,2 @@
17700
+218418
|
|
From: <pi...@gi...> - 2005-11-04 14:38:06
|
I got bitten by a heisenbug today. The code was doing pointer
arithmetic and storing temporary calculations in a 32bit integer. Thus
it crashed when running in the normal enviroment but the binary ran
without problems when interpreted by valgrind.
The problem would have been easier pinpointed if the base memory
address used for 64bit architectures was high enough to make truncated
pointers invalid.
/=D8yvind K.
--
=ABThe future is already here. It's just not very evenly distributed=BB
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
|
|
From: <sv...@va...> - 2005-11-04 14:35:06
|
Author: sewardj
Date: 2005-11-04 14:34:52 +0000 (Fri, 04 Nov 2005)
New Revision: 1433
Log:
Handle jecxz in addition to jrcxz.
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-amd64/toIR.c 2005-11-04 14:18:31 UTC (rev 1432)
+++ trunk/priv/guest-amd64/toIR.c 2005-11-04 14:34:52 UTC (rev 1433)
@@ -11635,19 +11635,30 @@
DIP("j%s-8 0x%llx\n", name_AMD64Condcode(opc - 0x70), d64);
break;
=20
- case 0xE3: /* JRCXZ or perhaps JECXZ, depending on OSO ? Intel
- manual says it depends on address size override,
- which doesn't sound right to me. But the amd manual
- alsay says that, so I guess it is. In which case 8
- is the only valid size. */
- if (have66orF2orF3(pfx) || haveASO(pfx)) goto decode_failure;
+ case 0xE3:=20
+ /* JRCXZ or JECXZ, depending address size override. */
+ if (have66orF2orF3(pfx)) goto decode_failure;
d64 =3D (guest_RIP_bbstart+delta+1) + getSDisp8(delta);=20
delta++;
- stmt( IRStmt_Exit( binop(Iop_CmpEQ64, getIReg64(R_RCX), mkU64(0)),
- Ijk_Boring,
- IRConst_U64(d64))=20
- );
- DIP("jrcxz 0x%llx\n", d64);
+ if (haveASO(pfx)) {
+ /* 32-bit */
+ stmt( IRStmt_Exit( binop(Iop_CmpEQ64,=20
+ unop(Iop_32Uto64, getIReg32(R_RCX)),=20
+ mkU64(0)),
+ Ijk_Boring,
+ IRConst_U64(d64))=20
+ );
+ DIP("jecxz 0x%llx\n", d64);
+ } else {
+ /* 64-bit */
+ stmt( IRStmt_Exit( binop(Iop_CmpEQ64,=20
+ getIReg64(R_RCX),=20
+ mkU64(0)),
+ Ijk_Boring,
+ IRConst_U64(d64))=20
+ );
+ DIP("jrcxz 0x%llx\n", d64);
+ }
break;
=20
case 0xE0: /* LOOPNE disp8: decrement count, jump if count !=3D 0 && =
ZF=3D=3D0 */
|
|
From: <sv...@va...> - 2005-11-04 14:18:35
|
Author: sewardj
Date: 2005-11-04 14:18:31 +0000 (Fri, 04 Nov 2005)
New Revision: 1432
Log:
Handle address-size overrides in the common case (explicit memory referen=
ces).
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-amd64/toIR.c 2005-11-03 14:00:57 UTC (rev 1431)
+++ trunk/priv/guest-amd64/toIR.c 2005-11-04 14:18:31 UTC (rev 1432)
@@ -93,6 +93,35 @@
//.. should ever become relevant).
*/
=20
+/* Notes re address size overrides (0x67).
+
+ According to the AMD documentation (24594 Rev 3.09, Sept 2003,
+ "AMD64 Architecture Programmer's Manual Volume 3: General-Purpose
+ and System Instructions"), Section 1.2.3 ("Address-Size Override
+ Prefix"):
+
+ 0x67 applies to all explicit memory references, causing the top
+ 32 bits of the effective address to become zero.
+
+ 0x67 has no effect on stack references (push/pop); these always
+ use a 64-bit address.
+
+ 0x67 changes the interpretation of instructions which implicitly
+ reference RCX/RSI/RDI, so that in fact ECX/ESI/EDI are used
+ instead. These are:
+
+ cmp{s,sb,sw,sd,sq}
+ in{s,sb,sw,sd}
+ jcxz, jecxz, jrcxz
+ lod{s,sb,sw,sd,sq}
+ loop{,e,bz,be,z}
+ mov{s,sb,sw,sd,sq}
+ out{s,sb,sw,sd}
+ rep{,e,ne,nz}
+ sca{s,sb,sw,sd,sq}
+ sto{s,sb,sw,sd,sq}
+ xlat{,b} */
+
/* Translates AMD64 code to IR. */
=20
#include "libvex_basictypes.h"
@@ -1900,15 +1929,18 @@
=20
/* 'virtual' is an IRExpr* holding a virtual address. Convert it to a
linear address by adding any required segment override as indicated
- by sorb. */
+ by sorb, and also dealing with any address size override
+ present. */
static
-IRExpr* handleSegOverride ( Prefix pfx, IRExpr* virtual )
+IRExpr* handleAddrOverrides ( Prefix pfx, IRExpr* virtual )
{
+ /* --- segment overrides --- */
+
if (pfx & PFX_FS) {
/* Note that this is a linux-kernel specific hack that relies
on the assumption that %fs is always zero. */
/* return virtual + guest_FS_ZERO. */
- return binop(Iop_Add64, virtual, IRExpr_Get(OFFB_FS_ZERO, Ity_I64)=
);
+ virtual =3D binop(Iop_Add64, virtual, IRExpr_Get(OFFB_FS_ZERO, Ity=
_I64));
}
=20
if (pfx & PFX_GS) {
@@ -1916,6 +1948,11 @@
}
=20
/* cs, ds, es and ss are simply ignored in 64-bit mode. */
+
+ /* --- address size override --- */
+ if (haveASO(pfx))
+ virtual =3D unop(Iop_32Uto64, unop(Iop_64to32, virtual));
+
return virtual;
}
=20
@@ -1933,7 +1970,7 @@
//.. case 0x26: sreg =3D R_ES; break;
//.. case 0x64: sreg =3D R_FS; break;
//.. case 0x65: sreg =3D R_GS; break;
-//.. default: vpanic("handleSegOverride(x86,guest)");
+//.. default: vpanic("handleAddrOverrides(x86,guest)");
//.. }
//..=20
//.. hWordTy =3D sizeof(HWord)=3D=3D4 ? Ity_I32 : Ity_I64;
@@ -2033,7 +2070,7 @@
DIS(buf, "%s(%s)", sorbTxt(pfx), nameIRegRexB(8,pfx,rm));
*len =3D 1;
return disAMode_copy2tmp(
- handleSegOverride(pfx, getIRegRexB(8,pfx,rm)));
+ handleAddrOverrides(pfx, getIRegRexB(8,pfx,rm)));
}
=20
/* REX.B=3D=3D0: d8(%rax) ... d8(%rdi), not including d8(%rsp)=20
@@ -2050,7 +2087,7 @@
}
*len =3D 2;
return disAMode_copy2tmp(
- handleSegOverride(pfx,
+ handleAddrOverrides(pfx,
binop(Iop_Add64,getIRegRexB(8,pfx,rm),mkU64(d))));
}
=20
@@ -2064,7 +2101,7 @@
DIS(buf, "%s%lld(%s)", sorbTxt(pfx), d, nameIRegRexB(8,pfx,rm=
));
*len =3D 5;
return disAMode_copy2tmp(
- handleSegOverride(pfx,
+ handleAddrOverrides(pfx,
binop(Iop_Add64,getIRegRexB(8,pfx,rm),mkU64(d))));
}
=20
@@ -2089,7 +2126,7 @@
guest_RIP_next_assumed =3D guest_RIP_bbstart=20
+ delta+4 + extra_bytes;
return disAMode_copy2tmp(=20
- handleSegOverride(pfx,=20
+ handleAddrOverrides(pfx,=20
binop(Iop_Add64, mkU64(guest_RIP_next_assumed),=20
mkU64(d))));
}
@@ -2133,7 +2170,7 @@
*len =3D 2;
return
disAMode_copy2tmp(=20
- handleSegOverride(pfx,
+ handleAddrOverrides(pfx,
binop(Iop_Add64,=20
getIRegRexB(8,pfx,base_r),
binop(Iop_Shl64, getIReg64rexX(pfx,index_r),
@@ -2147,7 +2184,7 @@
*len =3D 6;
return
disAMode_copy2tmp(
- handleSegOverride(pfx,=20
+ handleAddrOverrides(pfx,=20
binop(Iop_Add64,
binop(Iop_Shl64, getIReg64rexX(pfx,index_r),=20
mkU8(scale)),
@@ -2158,7 +2195,7 @@
DIS(buf, "%s(%s)", sorbTxt(pfx), nameIRegRexB(8,pfx,base_r))=
;
*len =3D 2;
return disAMode_copy2tmp(
- handleSegOverride(pfx, getIRegRexB(8,pfx,base_r)));
+ handleAddrOverrides(pfx, getIRegRexB(8,pfx,base_r)));
}
=20
if (index_is_SP && base_is_BPor13) {
@@ -2166,7 +2203,7 @@
DIS(buf, "%s%lld", sorbTxt(pfx), d);
*len =3D 6;
return disAMode_copy2tmp(
- handleSegOverride(pfx, mkU64(d)));
+ handleAddrOverrides(pfx, mkU64(d)));
}
=20
vassert(0);
@@ -2193,7 +2230,7 @@
d, nameIRegRexB(8,pfx,base_r));
*len =3D 3;
return disAMode_copy2tmp(
- handleSegOverride(pfx,=20
+ handleAddrOverrides(pfx,=20
binop(Iop_Add64, getIRegRexB(8,pfx,base_r), mkU64(=
d)) ));
} else {
if (scale =3D=3D 0) {
@@ -2208,7 +2245,7 @@
*len =3D 3;
return=20
disAMode_copy2tmp(
- handleSegOverride(pfx,
+ handleAddrOverrides(pfx,
binop(Iop_Add64,
binop(Iop_Add64,=20
getIRegRexB(8,pfx,base_r),=20
@@ -2240,7 +2277,7 @@
d, nameIRegRexB(8,pfx,base_r));
*len =3D 6;
return disAMode_copy2tmp(
- handleSegOverride(pfx,=20
+ handleAddrOverrides(pfx,=20
binop(Iop_Add64, getIRegRexB(8,pfx,base_r), mkU64(=
d)) ));
} else {
if (scale =3D=3D 0) {
@@ -2255,7 +2292,7 @@
*len =3D 6;
return=20
disAMode_copy2tmp(
- handleSegOverride(pfx,
+ handleAddrOverrides(pfx,
binop(Iop_Add64,
binop(Iop_Add64,=20
getIRegRexB(8,pfx,base_r),=20
@@ -7870,10 +7907,8 @@
}
=20
not_a_prefix:
+
/* Dump invalid combinations */
- if (pfx & PFX_ASO)=20
- goto decode_failure; /* don't support address-size override */
-
n =3D 0;
if (pfx & PFX_F2) n++;
if (pfx & PFX_F3) n++;
@@ -7890,6 +7925,9 @@
if (n > 1)=20
goto decode_failure; /* multiple seg overrides =3D=3D illegal */
=20
+ if (pfx & PFX_GS)
+ goto decode_failure; /* legal, but unsupported right now */
+
/* Set up sz. */
sz =3D 4;
if (pfx & PFX_66) sz =3D 2;
@@ -11728,7 +11766,7 @@
delta +=3D 8;
ty =3D szToITy(sz);
addr =3D newTemp(Ity_I64);
- assign( addr, handleSegOverride(pfx, mkU64(d64)) );
+ assign( addr, handleAddrOverrides(pfx, mkU64(d64)) );
putIRegRAX(sz, loadLE( ty, mkexpr(addr) ));
DIP("mov%c %s0x%llx, %s\n", nameISize(sz),=20
sorbTxt(pfx), d64,
@@ -11746,7 +11784,7 @@
delta +=3D 8;
ty =3D szToITy(sz);
addr =3D newTemp(Ity_I64);
- assign( addr, handleSegOverride(pfx, mkU64(d64)) );
+ assign( addr, handleAddrOverrides(pfx, mkU64(d64)) );
storeLE( mkexpr(addr), getIRegRAX(sz) );
DIP("mov%c %s, %s0x%llx\n", nameISize(sz), nameIRegRAX(sz),
sorbTxt(pfx), d64);
@@ -12475,6 +12513,8 @@
case 0xAE:
case 0xAF:
/* F2 AE/AF: repne scasb/repne scas{w,l,q} */
+ if (haveASO(pfx))=20
+ goto decode_failure;
if (haveF2(pfx) && !haveF3(pfx)) {
if (opc =3D=3D 0xAE)
sz =3D 1;
@@ -12497,6 +12537,8 @@
case 0xA6:
case 0xA7:
/* F3 A6/A7: repe cmps/rep cmps{w,l,q} */
+ if (haveASO(pfx))=20
+ goto decode_failure;
if (haveF3(pfx) && !haveF2(pfx)) {
if (opc =3D=3D 0xA6)
sz =3D 1;
@@ -12512,6 +12554,8 @@
case 0xAA:
case 0xAB:
/* F3 AA/AB: rep stosb/rep stos{w,l,q} */
+ if (haveASO(pfx))=20
+ goto decode_failure;
if (haveF3(pfx) && !haveF2(pfx)) {
if (opc =3D=3D 0xAA)
sz =3D 1;
@@ -12534,6 +12578,8 @@
case 0xA4:
case 0xA5:
/* F3 A4: rep movsb */
+ if (haveASO(pfx))=20
+ goto decode_failure;
if (haveF3(pfx) && !haveF2(pfx)) {
if (opc =3D=3D 0xA4)
sz =3D 1;
@@ -12625,7 +12671,7 @@
//.. //-- case 0xD7: /* XLAT */
//.. //-- t1 =3D newTemp(cb); t2 =3D newTemp(cb);
//.. //-- uInstr2(cb, GET, sz, ArchReg, R_EBX, TempReg, t1); /* ge=
t eBX */
-//.. //-- handleSegOverride( cb, sorb, t1 ); /* make=
t1 DS:eBX */
+//.. //-- handleAddrOverrides( cb, sorb, t1 ); /* ma=
ke t1 DS:eBX */
//.. //-- uInstr2(cb, GET, 1, ArchReg, R_AL, TempReg, t2); /* get =
AL */
//.. //-- /* Widen %AL to 32 bits, so it's all defined when we add=
it. */
//.. //-- uInstr1(cb, WIDEN, 4, TempReg, t2);
|
|
From: <sv...@va...> - 2005-11-04 14:11:21
|
Author: tom
Date: 2005-11-04 14:11:05 +0000 (Fri, 04 Nov 2005)
New Revision: 4999
Log:
Make the tool writing documentation align a bit more closely
with reality.
Modified:
trunk/docs/xml/writing-tools.xml
Modified: trunk/docs/xml/writing-tools.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/xml/writing-tools.xml 2005-11-04 12:27:58 UTC (rev 4998)
+++ trunk/docs/xml/writing-tools.xml 2005-11-04 14:11:05 UTC (rev 4999)
@@ -35,7 +35,7 @@
between its "core" and "tools".</para>
=20
<para>The core provides the common low-level infrastructure to
-support program instrumentation, including the x86-to-x86 JIT
+support program instrumentation, including the JIT
compiler, low-level memory manager, signal handling and a
scheduler (for pthreads). It also provides certain services that
are useful to some but not all tools, such as support for error
@@ -43,8 +43,8 @@
=20
<para>But the core leaves certain operations undefined, which
must be filled by tools. Most notably, tools define how program
-code should be instrumented. They can also define certain
-variables to indicate to the core that they would like to use
+code should be instrumented. They can also call certain
+functions to indicate to the core that they would like to use
certain services, or be notified when certain interesting events
occur. But the core takes care of all the hard work.</para>
=20
@@ -81,7 +81,7 @@
(<computeroutput>malloc()</computeroutput> etc.)</para>
</listitem>
<listitem>
- <para>Pthread operations and scheduling</para>
+ <para>Thread scheduling</para>
</listitem>
<listitem>
<para>Signal handling</para>
@@ -177,7 +177,7 @@
<para><command>lackey</command>: does simple counting of
various things: the number of calls to a particular function
(<computeroutput>_dl_runtime_resolve()</computeroutput>); the
- number of basic blocks, x86 instruction, UCode instructions
+ number of basic blocks, guest instructions, VEX instructions
executed; the number of branches executed and the proportion of
them which were taken.</para>
</listitem>
@@ -281,29 +281,18 @@
<title>How tools work</title>
=20
<para>Tools must define various functions for instrumenting
-programs that are called by Valgrind's core, yet they must be
-implemented in such a way that they can be written and compiled
-without touching Valgrind's core. This is important, because one
-of our aims is to allow people to write and distribute their own
-tools that can be plugged into Valgrind's core easily.</para>
+programs that are called by Valgrind's core. They are then linked
+against the coregrind library
+(<computeroutput>libcoregrind.a</computeroutput>) that valgrind
+provides as well as the VEX library
+(<computeroutput>libvex.a</computeroutput>) that also comes with
+valgrind and provides the JIT engine.
=20
-<para>This is achieved by packaging each tool into a separate
-shared object which is then loaded ahead of the core shared
-object <computeroutput>valgrind.so</computeroutput>, using the
-dynamic linker's <computeroutput>LD_PRELOAD</computeroutput>
-variable. Any functions defined in the tool that share the name
-with a function defined in core (such as the instrumentation
-function <computeroutput>instrument()</computeroutput>)
-override the core's definition. Thus the core can call the
-necessary tool functions.</para>
+<para>Each tool is linked as a statically linked program and placed
+in the valgrind library directory from where valgrind will load it
+automatically when the <computeroutput>--tool</computeroutput> option
+is used to select it.</para>
=20
-<para>This magic is all done for you; the shared object used is
-chosen with the <computeroutput>--tool</computeroutput> option to
-the <computeroutput>valgrind</computeroutput> startup script.
-The default tool used is
-<computeroutput>memcheck</computeroutput>, Valgrind's original
-memory checker.</para>
-
</sect2>
=20
=20
@@ -357,8 +346,8 @@
trying to understand this file, at least a little; you might
have to do more complicated things with it later on. In
particular, the name of the
- <computeroutput>vgtool_foobar_so_SOURCES</computeroutput>
- variable determines the name of the tool's shared object, which
+ <computeroutput>foobar_SOURCES</computeroutput>
+ variable determines the name of the tool, which
determines what name must be passed to the
<computeroutput>--tool</computeroutput> option to use the
tool.</para>
@@ -396,8 +385,7 @@
make install]]></programlisting>
=20
<para>It should automake, configure and compile without
- errors, putting copies of the tool's shared object
- <computeroutput>vgtool_foobar.so</computeroutput> in
+ errors, putting copies of the tool in
<computeroutput>foobar/</computeroutput> and
<computeroutput>inst/lib/valgrind/</computeroutput>.</para>
</listitem>
@@ -458,7 +446,7 @@
=20
<para>In addition, if a tool wants to use some of the optional
services provided by the core, it may have to define other
-functions.</para>
+functions and tell the code about them.</para>
=20
</sect2>
=20
@@ -509,9 +497,8 @@
<computeroutput>VG_(track_*)()</computeroutput>. These include
things such as blocks of memory being malloc'd, the stack pointer
changing, a mutex being locked, etc. If a tool wants to know
-about this, it should set the relevant pointer in the structure
-to point to a function, which will be called when that event
-happens.</para>
+about this, it should provide a pointer to a function, which will
+be called when that event happens.</para>
=20
<para>For example, if the tool want to be notified when a new
block of memory is malloc'd, it should call
@@ -532,21 +519,16 @@
=20
<para><computeroutput>instrument()</computeroutput> is the
interesting one. It allows you to instrument
-<emphasis>UCode</emphasis>, which is Valgrind's RISC-like
-intermediate language. UCode is described in=20
+<emphasis>VEX IR</emphasis>, which is Valgrind's RISC-like
+intermediate language. VEX IR is described in=20
<xref linkend=3D"mc-tech-docs.ucode"/>.</para>
=20
-<para>The easiest way to instrument UCode is to insert calls to C
+<para>The easiest way to instrument VEX IR is to insert calls to C
functions when interesting things happen. See the tool "Lackey"
(<filename>lackey/lk_main.c</filename>) for a simple example of
this, or Cachegrind (<filename>cachegrind/cg_main.c</filename>)
for a more complex example.</para>
=20
-<para>A much more complicated way to instrument UCode, albeit one
-that might result in faster instrumented programs, is to extend
-UCode with new UCode instructions. This is recommended for
-advanced Valgrind hackers only! See Memcheck for an example.</para>
-
</sect2>
=20
=20
@@ -576,7 +558,7 @@
a tool should need to
<computeroutput>#include</computeroutput>.</para>
=20
-<para>In particular, you probably shouldn't use anything from the
+<para>In particular, you can't use anything from the
C library (there are deep reasons for this, trust us). Valgrind
provides an implementation of a reasonable subset of the C
library, details of which are in
@@ -592,13 +574,9 @@
Addrcheck, Cachegrind, Lackey, etc.) are probably the best
documentation of all, for the moment.</para>
=20
-<para>Note that the <computeroutput>VG_</computeroutput> and
-<computeroutput>TL_</computeroutput> macros are used heavily.
-These just prepend longer strings in front of names to avoid
-potential namespace clashes. We strongly recommend using the
-<computeroutput>TL_</computeroutput> macro for any global
-functions and variables in your tool, or writing a similar
-macro.</para>
+<para>Note that the <computeroutput>VG_</computeroutput> macro is used
+heavily. This just prepends a longer string in front of names to
+avoid potential namespace clashes.</para>
=20
</sect2>
=20
@@ -672,9 +650,9 @@
<sect3 id=3D"writing-tools.ucode-probs">
<title>UCode Instrumentation Problems</title>
=20
-<para>If you are having problems with your UCode instrumentation,
+<para>If you are having problems with your VEX UIR instrumentation,
it's likely that GDB won't be able to help at all. In this case,
-Valgrind's <computeroutput>--trace-codegen</computeroutput>
+Valgrind's <computeroutput>--trace-flags</computeroutput>
option is invaluable for observing the results of
instrumentation.</para>
=20
@@ -690,7 +668,7 @@
than using GDB.</para>
=20
<para>The other debugging command line options can be useful too
-(run <computeroutput>valgrind -h</computeroutput> for the
+(run <computeroutput>valgrind --help-debug</computeroutput> for the
list).</para>
=20
</sect3>
|
|
From: Julian S. <js...@ac...> - 2005-11-04 12:52:22
|
> 1 Is there any API to get the original instruction? > 2 If no such API in valgrind, do you think it is necessary to implement > such API in valgrind? And can someone show me where should I start to > investigate it? Why do you want to read the original instruction? What will you do with this information? J |
|
From: <sv...@va...> - 2005-11-04 12:28:10
|
Author: tom Date: 2005-11-04 12:27:58 +0000 (Fri, 04 Nov 2005) New Revision: 4998 Log: Remove remaining references to the old tool.h header. Modified: trunk/docs/xml/writing-tools.xml Modified: trunk/docs/xml/writing-tools.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/writing-tools.xml 2005-11-04 12:17:20 UTC (rev 4997) +++ trunk/docs/xml/writing-tools.xml 2005-11-04 12:27:58 UTC (rev 4998) @@ -23,9 +23,7 @@ quite a few things about Valgrind, it is much easier than instrumenting a program from scratch yourself.</para> =20 -<para>[Nb: What follows is slightly out of date. In particular, -there are various references to a file include/tool.h which has been -split into a number of header files in include/.]</para> +<para>[Nb: What follows is slightly out of date.]</para> =20 </sect2> =20 @@ -572,25 +570,25 @@ important points, but there are undoubtedly many others that I should note but haven't thought of.</para> =20 -<para>The file <filename>include/tool.h</filename> contains +<para>The files <filename>include/pub_tool_*.h</filename> contain all the types, macros, functions, etc. that a tool should -(hopefully) need, and is the only <filename>.h</filename> file a -tool should need to +(hopefully) need, and are the only <filename>.h</filename> files +a tool should need to <computeroutput>#include</computeroutput>.</para> =20 <para>In particular, you probably shouldn't use anything from the C library (there are deep reasons for this, trust us). Valgrind provides an implementation of a reasonable subset of the C library, details of which are in -<filename>tool.h</filename>.</para> +<filename>pub_tool_libc*.h</filename>.</para> =20 <para>Similarly, when writing a tool, you shouldn't need to look at any of the code in Valgrind's core. Although it might be useful sometimes to help understand something.</para> =20 -<para><filename>tool.h</filename> has a reasonable amount of -documentation in it that should hopefully be enough to get you -going. But ultimately, the tools distributed (Memcheck, +<para>The <filename>pub_tool_*.h</filename> files have a reasonable +amount of documentation in it that should hopefully be enough to get +you going. But ultimately, the tools distributed (Memcheck, Addrcheck, Cachegrind, Lackey, etc.) are probably the best documentation of all, for the moment.</para> =20 |
|
From: <sv...@va...> - 2005-11-04 12:17:28
|
Author: tom
Date: 2005-11-04 12:17:20 +0000 (Fri, 04 Nov 2005)
New Revision: 4997
Log:
Tool writing documentation updates from Yao Qi <qiy...@cn...>.
Modified:
trunk/docs/xml/writing-tools.xml
Modified: trunk/docs/xml/writing-tools.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/xml/writing-tools.xml 2005-11-04 11:31:33 UTC (rev 4996)
+++ trunk/docs/xml/writing-tools.xml 2005-11-04 12:17:20 UTC (rev 4997)
@@ -93,7 +93,7 @@
<para>A tool has no control over these operations; it never
"sees" the code doing this work and thus cannot instrument it.
However, the core provides hooks so a tool can be notified
- when certain interesting events happen, for example when when
+ when certain interesting events happen, for example when
dynamic memory is allocated or freed, the stack pointer is
changed, or a pthread mutex is locked, etc.</para>
=20
@@ -181,7 +181,7 @@
(<computeroutput>_dl_runtime_resolve()</computeroutput>); the
number of basic blocks, x86 instruction, UCode instructions
executed; the number of branches executed and the proportion of
- those which were taken.</para>
+ them which were taken.</para>
</listitem>
</itemizedlist>
=20
@@ -315,7 +315,8 @@
<para>To write your own tool, you'll need the Valgrind source code.
A normal source distribution should do, although you might want to
check out the latest code from the Subversion repository. See the
-information about how to do so at <ulink url=3D"http://www.valgrind.org/=
">the
+information about how to do so at
+<ulink url=3D"http://www.valgrind.org/downloads/repository.html">the
Valgrind website</ulink>.</para>
=20
</sect2>
@@ -494,16 +495,15 @@
extra information about malloc'd blocks, etc.</para>
=20
<para>For example, if a tool wants the core's help in recording
-and reporting errors, it must set the
-<computeroutput>tool_errors</computeroutput> need to
-<computeroutput>True</computeroutput>, and then provide
-definitions of six functions for comparing errors, printing out
+and reporting errors, it must call
+<computeroutput>VG_(needs_tool_errors)</computeroutput> and provide
+definitions of eight functions for comparing errors, printing out
errors, reading suppressions from a suppressions file, etc.
While writing these functions requires some work, it's much less
than doing error handling from scratch because the core is doing
-most of the work. See the type
-<computeroutput>VgNeeds</computeroutput> in
-<filename>include/tool.h</filename> for full details of all
+most of the work. See the function
+<computeroutput>VG_(needs_tool_errors)</computeroutput> in
+<filename>include/pub_tool_tooliface.h</filename> for full details of al=
l
the needs.</para>
=20
<para>Third, the tool can indicate which events in core it wants
@@ -523,7 +523,7 @@
=20
<para>More information about "details", "needs" and "trackable
events" can be found in
-<filename>include/tool.h</filename>.</para>
+<filename>include/pub_tool_tooliface.h</filename>.</para>
=20
</sect2>
=20
@@ -688,8 +688,8 @@
=20
<para>If you just want to know whether a program point has been
reached, using the <computeroutput>OINK</computeroutput> macro
-(in <filename>include/tool.h</filename>) can be easier than
-using GDB.</para>
+(in <filename>include/pub_tool_libcprint.h</filename>) can be easier
+than using GDB.</para>
=20
<para>The other debugging command line options can be useful too
(run <computeroutput>valgrind -h</computeroutput> for the
@@ -808,7 +808,7 @@
</listitem>
=20
<listitem>
- <para>Write the documentation. There are some helpful bits and
+ <para>Write the documentation. There are some helpful bits and
pieces on using xml markup in
<filename>valgrind/docs/xml/xml_help.txt</filename>.</para>
</listitem>
@@ -1124,8 +1124,8 @@
<computeroutput>VGP_POPCC</computeroutput> macros to record time
spent doing certain things. New profiling event numbers must not
overlap with the core profiling event numbers. See
-<filename>include/tool.h</filename> for details and Memcheck
-for an example.</para>
+<filename>include/pub_tool_profile.h</filename> for details and
+Memcheck for an example.</para>
=20
</sect2>
=20
|
|
From: Josef W. <Jos...@gm...> - 2005-11-04 12:15:30
|
On Friday 04 November 2005 12:56, Yao Qi wrote: > > Well if you've got the address and the length then just read it > > from that address! > > I have considered this solution previously, and it is an effective way to > read every guest instruction in '.text' section from the client. However, > it will break the integrity and encapsulation of the CLIENT--CORE--TOOL > orgnization of valgrind. That reasoning is quite academic and not really helpful. If you can read from client memory yourself, what is the purpose of providing a function char[] VG_(please_core_read_this_memory_for_me)(void* addr, int size) ? It would be better if you can describe what you want to achieve. Do you want to pass the guest instructions to some other tool? Or are you only interested in analysing the guest instruction yourself? Whatever the tool would do with the pure guest instruction, it most probably would make the tool architecture dependent, which better should be avoided (maintenance for each architecuture needed etc.) > Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf) Your function name suggests that you want to have a description of the guest instruction, and not the guest instruction itself. Why not use the description that VEX provides about the guest instruction (e.g. type of command, number of operands, type of operands and so on). If you think that some description is missing it would be better to enhance VEX to provide it. Josef |
|
From: Tom H. <to...@co...> - 2005-11-04 12:08:39
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> Yes. I am puzzled by some points in docs/xml/writing-tools.xml, for example
> include/tool.h. This file name appeared several times in this document, but I
> could not find it in valgrind source code, although it is said that this file
> has been split into a number of header files in include/.
The tool.h file no longer exists - it has been split into separate
files for each module - the pub_tool_*.h files that Nick mentioned.
So you've found an out of date piece of documentation I'm afraid.
> I have modified some of them, and here go a patch for your reference.
> Would you like to take a look? Any suggestions and comments are highly
> appreciated!
I'll have a look at the patch. Thanks for supplying it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-04 12:04:22
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> Tom Hughes wrote:
>> In message <436...@cn...>
>> Yao Qi <qiy...@cn...> wrote:
>>
>>>I am thinking of how to map IRStmt to guest original instruction in
>>>valgrind tool. I find that there are some funtions relative to this
>>>purpose in include/pub_tool_debuginfo.h and
>>>include/pub_tool_execontext.h. I could only get address and length of
>>>every original instruction per IRStmt, but how could I get the content
>>>of guest instructions?
>> Well if you've got the address and the length then just read it
>> from that address!
>
> I have considered this solution previously, and it is an effective way to
> read every guest instruction in '.text' section from the client. However,
> it will break the integrity and encapsulation of the CLIENT--CORE--TOOL
> orgnization of valgrind.
There has never been any prohibition on tools reading areas of the
client memory - there was a prohibition on clients reading core and
tool memory but even that is now gone although we certainly wouldn't
want to encourage it.
> All the machine instructions of CLIENT are translated to an intermediate
> representation and optimized by CORE, and TOOL get all the information
> of CLIENT from CORE, so now if My tool read machine instruction directly
> from CLIENT bypass CORE, it would not be a best solution to this problem.
> The coregrind/m_debuginfo/symtab.c is a good example that TOOL get all the
> information from CORE instead of from CLIENT directly.
Because decoding the symbol table is a complex operation that the
core already needs to do so it makes sense to expose it to the tools
for them to use.
> Maybe, I did not describe my ideas clearly, and what I want to say is,
>
> 1 Is there any API to get the original instruction?
No. Unless you count VG_(memcpy) that is ;-)
> 2 If no such API in valgrind, do you think it is necessary to implement
> such API in valgrind? And can someone show me where should I start to
> investigate it?
I still don't understand the point, but here is an implementation
of such an API if you want it:
void VG_(get_instruction)(Addr addr, Int length, UChar *buf)
{
VG_(memcpy)(buf, addr, length);
}
> Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf)
> could do this, but it seems that the SegInfo do not save enought
> information about '.text' segment, so I am not sure that the CORE should
> be enhaunced to support TOOL's feature of mapping IRStmt to original
> instruction.
What sort of information about the test segment do you think is
needed? If you have the address of the instruction and it's length
then what else do you need?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yao Qi <qiy...@cn...> - 2005-11-04 11:57:03
|
Tom Hughes wrote: > In message <436...@cn...> > Yao Qi <qiy...@cn...> wrote: > > >>I am thinking of how to map IRStmt to guest original instruction in >>valgrind tool. I find that there are some funtions relative to this >>purpose in include/pub_tool_debuginfo.h and >>include/pub_tool_execontext.h. I could only get address and length of >>every original instruction per IRStmt, but how could I get the content >>of guest instructions? > > > Well if you've got the address and the length then just read it > from that address! I have considered this solution previously, and it is an effective way to read every guest instruction in '.text' section from the client. However, it will break the integrity and encapsulation of the CLIENT--CORE--TOOL orgnization of valgrind. All the machine instructions of CLIENT are translated to an intermediate representation and optimized by CORE, and TOOL get all the information of CLIENT from CORE, so now if My tool read machine instruction directly from CLIENT bypass CORE, it would not be a best solution to this problem. The coregrind/m_debuginfo/symtab.c is a good example that TOOL get all the information from CORE instead of from CLIENT directly. Maybe, I did not describe my ideas clearly, and what I want to say is, 1 Is there any API to get the original instruction? 2 If no such API in valgrind, do you think it is necessary to implement such API in valgrind? And can someone show me where should I start to investigate it? Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf) could do this, but it seems that the SegInfo do not save enought information about '.text' segment, so I am not sure that the CORE should be enhaunced to support TOOL's feature of mapping IRStmt to original instruction. I would be grateful if someone could take some time out to answer these. Thanks in advance! -- Regards, Yao Yao Qi |
|
From: Yao Qi <qiy...@cn...> - 2005-11-04 11:43:03
|
Nicholas Nethercote wrote:
> On Thu, 3 Nov 2005, Yao Qi wrote:
>
>> I have browsed source code and document for some days but I could not
>> find
>> this global variable. A document about valgrind tool API may be needed
>> for valgrind tool developers to reference. I am thinking of the name and
>> the format of this document, anyone could confirm or deny this?
>
>
> The tool API is defined by the include/pub_tool_*.h files.
>
> There is some internal documentation in docs/internals/ which you may
> find useful, in particular module-structure.txt. The other files in
> that directory are a mixed bag of things that we decided were worth
> keeping.
Thanks for your kind help.
>
> The documentation for writing tools is not good. It would be great to
> improve it. The hard part is keeping documentation up to date.
Yes. I am puzzled by some points in docs/xml/writing-tools.xml, for example
include/tool.h. This file name appeared several times in this document, but I
could not find it in valgrind source code, although it is said that this file
has been split into a number of header files in include/.
I have modified some of them, and here go a patch for your reference.
Would you like to take a look? Any suggestions and comments are highly
appreciated!
Index: docs/xml/writing-tools.xml
===================================================================
--- docs/xml/writing-tools.xml (revision 4995)
+++ docs/xml/writing-tools.xml (working copy)
@@ -93,7 +93,7 @@
<para>A tool has no control over these operations; it never
"sees" the code doing this work and thus cannot instrument it.
However, the core provides hooks so a tool can be notified
- when certain interesting events happen, for example when when
+ when certain interesting events happen, for example when
dynamic memory is allocated or freed, the stack pointer is
changed, or a pthread mutex is locked, etc.</para>
@@ -114,7 +114,7 @@
tool to wrap system calls.</para>
</listitem>
<listitem>
- <para>Other: all other kernel activity (e.g. process
+ <para>Others: all other kernel activitives (e.g. process
scheduling) is totally opaque and irrelevant to the
program.</para>
</listitem>
@@ -181,7 +181,7 @@
(<computeroutput>_dl_runtime_resolve()</computeroutput>); the
number of basic blocks, x86 instruction, UCode instructions
executed; the number of branches executed and the proportion of
- those which were taken.</para>
+ them which were taken.</para>
</listitem>
</itemizedlist>
@@ -315,7 +315,8 @@
<para>To write your own tool, you'll need the Valgrind source code.
A normal source distribution should do, although you might want to
check out the latest code from the Subversion repository. See the
-information about how to do so at <ulink url="http://www.valgrind.org/">the
+information about how to do so at
+<ulink url="http://www.valgrind.org/downloads/repository.html">the
Valgrind website</ulink>.</para>
</sect2>
@@ -503,7 +504,7 @@
than doing error handling from scratch because the core is doing
most of the work. See the type
<computeroutput>VgNeeds</computeroutput> in
-<filename>include/tool.h</filename> for full details of all
+<filename>coregrind/pub_core_tooliface.h</filename> for full details of all
the needs.</para>
<para>Third, the tool can indicate which events in core it wants
@@ -523,7 +524,7 @@
<para>More information about "details", "needs" and "trackable
events" can be found in
-<filename>include/tool.h</filename>.</para>
+<filename>include/pub_tool_tooliface.h</filename>.</para>
</sect2>
@@ -688,8 +689,8 @@
<para>If you just want to know whether a program point has been
reached, using the <computeroutput>OINK</computeroutput> macro
-(in <filename>include/tool.h</filename>) can be easier than
-using GDB.</para>
+(in <filename>include/pub_tool_libcprint.h</filename>) can be easier
+than using GDB.</para>
<para>The other debugging command line options can be useful too
(run <computeroutput>valgrind -h</computeroutput> for the
@@ -808,7 +809,7 @@
</listitem>
<listitem>
- <para>Write the documentation. There are some helpful bits and
+ <para>Write the documentation. There are some helpful bits and
pieces on using xml markup in
<filename>valgrind/docs/xml/xml_help.txt</filename>.</para>
</listitem>
@@ -1124,8 +1125,8 @@
<computeroutput>VGP_POPCC</computeroutput> macros to record time
spent doing certain things. New profiling event numbers must not
overlap with the core profiling event numbers. See
-<filename>include/tool.h</filename> for details and Memcheck
-for an example.</para>
+<filename>include/pub_tool_profile.h</filename> for details and
+Memcheck for an example.</para>
</sect2>
--
Regards, Yao
Yao Qi
|
|
From: Tom H. <to...@co...> - 2005-11-04 11:36:51
|
In message <17018.194.109.230.85.1131099944.squirrel@194.109.230.85>
Jeroen N. Witmond <jn...@xs...> wrote:
> In blanket, when I use tl_assert(false) or VG_(tool_panic)("Text") I get a
> stack trace without function name, source file and line number
> information:
>
> Blanket: the 'impossible' happened:
> Cannot determine order of keys: 4000C22:4000C27 <=> 4000C20:4000C22
> ==6748== at 0xB00015DA: ???
> ==6748== by 0xB00015D9: ???
> [11 similar lines removed]
>
> Module .in_place/blanket does contain debugging information, so `readelf
> -w` tells me. I cannot find an open bug report for this problem. Can
> anybody shed some light on this?
No idea I'm afraid - it seems to work for me on x86 systems with
a tl_assert call inserted in nl_instrument in the none tool.
There are some issues on amd64 - one I have just committed a fix
for but the other is more complicated.
The second issue is that when report_and_quit gets the initial
context it does this:
ip = (Addr)__builtin_return_address(0);
GET_REAL_SP_AND_FP(sp, fp);
The problem is that by doing that we get the return address (which
is in the calling function) but the current functions stack and frame
pointers which means that a CFI unwind fails because it looks up the
calling function's CFI data and tries to adjust the SP to get the
address of the CFA but as the SP value is bogus it doesn't find it
and the unwind fails.
As there is no reliable/easy way to get the calling functions stack
and frame pointers my best fix at the moment is to use the current
value of the PC instead of the return address. A patch for that is
attached which works on x86/amd64 but needs a small assembly tweak
for ppc32 to get the PC value.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-11-04 11:31:41
|
Author: tom
Date: 2005-11-04 11:31:33 +0000 (Fri, 04 Nov 2005)
New Revision: 4996
Log:
When unwinding the stack on x86/amd64 subtract one from the value of
ip before starting a new pass of the loop.
The reason for this is that (except for the first pass of the loop) the
value of ip is actually a return address, which is therefore after the
instruction that was executing at the time. This means that if there is
a boundary in the CFI information at that point we can wind up using the
wrong CFI data to do the next unwind if we do it based on the return
address.
This most commonly happens with a tail call where we wind up using the
data for the next function to do the unwind and getting hopelessly lost.
Modified:
trunk/coregrind/m_stacktrace.c
Modified: trunk/coregrind/m_stacktrace.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_stacktrace.c 2005-11-03 16:24:53 UTC (rev 4995)
+++ trunk/coregrind/m_stacktrace.c 2005-11-04 11:31:33 UTC (rev 4996)
@@ -124,6 +124,7 @@
ips[i++] =3D ip;
if (debug)
VG_(printf)(" ipsC[%d]=3D%08p\n", i-1, ips[i-1]);
+ ip =3D ip - 1;
continue;
}
=20
@@ -145,6 +146,7 @@
ips[i++] =3D ip;
if (debug)
VG_(printf)(" ipsF[%d]=3D%08p\n", i-1, ips[i-1]);
+ ip =3D ip - 1;
continue;
}
=20
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-11-04 10:26:00
|
Greetings,
In blanket, when I use tl_assert(false) or VG_(tool_panic)("Text") I get a
stack trace without function name, source file and line number
information:
Blanket: the 'impossible' happened:
Cannot determine order of keys: 4000C22:4000C27 <=> 4000C20:4000C22
==6748== at 0xB00015DA: ???
==6748== by 0xB00015D9: ???
[11 similar lines removed]
Module .in_place/blanket does contain debugging information, so `readelf
-w` tells me. I cannot find an open bug report for this problem. Can
anybody shed some light on this?
Thanks.
Jeroen.
PS: Debian 3,1 (sarge), Linux 2.4.26-1-386, gcc version 3.3.5 (Debian
1:3.3.5-13), Valgrind rev. 4995, VEX rev. 1431.
|
|
From: <js...@ac...> - 2005-11-04 03:52:30
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-11-04 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 200 tests, 83 stderr failures, 3 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree (stderr) memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badloop (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/badrw (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/doublefree (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (stderr) memcheck/tests/malloc_usable (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel2 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/memalign2 (stderr) memcheck/tests/memalign_test (stderr) memcheck/tests/memcmptest (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/mmaptest (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/nanoleak_supp (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/null_socket (stderr) memcheck/tests/oset_test (stderr) memcheck/tests/overlap (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pipe (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/str_tester (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/with-space (stderr) memcheck/tests/writev (stderr) memcheck/tests/x86/fpeflags (stderr) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_exit_group (stderr) memcheck/tests/x86/scalar_fork (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/scalar_vfork (stderr) memcheck/tests/x86/tronical (stderr) memcheck/tests/xml1 (stderr) memcheck/tests/zeropage (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2005-11-04 03:44:44
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-11-04 04:40:00 CET Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 167 tests, 17 stderr failures, 1 stdout failure ================= memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stderr) massif/tests/toobig-allocs (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2005-11-04 03:37:01
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-11-04 03:30:06 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 201 tests, 6 stderr failures, 1 stdout failure =================
memcheck/tests/leak-tree (stderr)
memcheck/tests/mempool (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/x86/scalar (stderr)
none/tests/mremap2 (stdout)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
make[4]: Leaving directory `/tmp/valgrind.11061/valgrind/VEX'
gcc -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -m32 -Wa,-gstabs -Wno-long-long -c -o dispatch-x86-linux.o `test -f 'm_dispatch/dispatch-x86-linux.S' || echo './'`m_dispatch/dispatch-x86-linux.S
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11061/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11061/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
m_scheduler/scheduler.c: In function 'name_of_sched_event':
m_scheduler/scheduler.c:153: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
m_scheduler/scheduler.c:153: error: for each function it appears in.)
m_scheduler/scheduler.c: In function 'vgPlain_scheduler':
m_scheduler/scheduler.c:719: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:820: error: 'VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
make[3]: *** [scheduler.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.11061/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.11061/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.11061/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Nov 4 03:31:28 2005
--- new.short Fri Nov 4 03:36:52 2005
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- make[4]: Leaving directory `/tmp/valgrind.11061/valgrind/VEX'
- gcc -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -m32 -Wa,-gstabs -Wno-long-long -c -o dispatch-x86-linux.o `test -f 'm_dispatch/dispatch-x86-linux.S' || echo './'`m_dispatch/dispatch-x86-linux.S
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11061/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
- then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11061/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
- m_scheduler/scheduler.c: In function 'name_of_sched_event':
- m_scheduler/scheduler.c:153: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
- m_scheduler/scheduler.c:153: error: for each function it appears in.)
- m_scheduler/scheduler.c: In function 'vgPlain_scheduler':
- m_scheduler/scheduler.c:719: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:820: error: 'VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
- make[3]: *** [scheduler.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.11061/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.11061/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.11061/valgrind'
- make: *** [all] Error 2
--- 3,17 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 201 tests, 6 stderr failures, 1 stdout failure =================
! memcheck/tests/leak-tree (stderr)
! memcheck/tests/mempool (stderr)
! memcheck/tests/pointer-trace (stderr)
! memcheck/tests/x86/scalar (stderr)
! none/tests/mremap2 (stdout)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
|
|
From: Tom H. <th...@cy...> - 2005-11-04 03:23:55
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-11-04 03:15:03 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 200 tests, 16 stderr failures, 1 stdout failure =================
memcheck/tests/addressable (stderr)
memcheck/tests/describe-block (stderr)
memcheck/tests/erringfds (stderr)
memcheck/tests/leak-0 (stderr)
memcheck/tests/leak-cycle (stderr)
memcheck/tests/leak-regroot (stderr)
memcheck/tests/leak-tree (stderr)
memcheck/tests/match-overrun (stderr)
memcheck/tests/mempool (stderr)
memcheck/tests/nanoleak (stderr)
memcheck/tests/partiallydefinedeq (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/sigkill (stderr)
memcheck/tests/stack_changes (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
none/tests/x86/yield (stdout)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11609/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c
source='m_scheduler/scheduler.c' object='scheduler.o' libtool=no \
depfile='.deps/scheduler.Po' tmpdepfile='.deps/scheduler.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11609/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c
m_scheduler/scheduler.c: In function `name_of_sched_event':
m_scheduler/scheduler.c:153: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:153: (Each undeclared identifier is reported only once
m_scheduler/scheduler.c:153: for each function it appears in.)
m_scheduler/scheduler.c: In function `vgPlain_scheduler':
m_scheduler/scheduler.c:719: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:820: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
make[3]: *** [scheduler.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.11609/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.11609/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.11609/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Nov 4 03:17:40 2005
--- new.short Fri Nov 4 03:23:50 2005
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- depmode=gcc3 /bin/sh ../depcomp \
- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11609/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c
- source='m_scheduler/scheduler.c' object='scheduler.o' libtool=no \
- depfile='.deps/scheduler.Po' tmpdepfile='.deps/scheduler.TPo' \
- depmode=gcc3 /bin/sh ../depcomp \
- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.11609/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c
- m_scheduler/scheduler.c: In function `name_of_sched_event':
- m_scheduler/scheduler.c:153: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:153: (Each undeclared identifier is reported only once
- m_scheduler/scheduler.c:153: for each function it appears in.)
- m_scheduler/scheduler.c: In function `vgPlain_scheduler':
- m_scheduler/scheduler.c:719: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:820: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
- make[3]: *** [scheduler.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.11609/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.11609/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.11609/valgrind'
- make: *** [all] Error 2
--- 3,27 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 200 tests, 16 stderr failures, 1 stdout failure =================
! memcheck/tests/addressable (stderr)
! memcheck/tests/describe-block (stderr)
! memcheck/tests/erringfds (stderr)
! memcheck/tests/leak-0 (stderr)
! memcheck/tests/leak-cycle (stderr)
! memcheck/tests/leak-regroot (stderr)
! memcheck/tests/leak-tree (stderr)
! memcheck/tests/match-overrun (stderr)
! memcheck/tests/mempool (stderr)
! memcheck/tests/nanoleak (stderr)
! memcheck/tests/partiallydefinedeq (stderr)
! memcheck/tests/pointer-trace (stderr)
! memcheck/tests/sigkill (stderr)
! memcheck/tests/stack_changes (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
! none/tests/x86/yield (stdout)
|
|
From: Tom H. <th...@cy...> - 2005-11-04 03:22:03
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-11-04 03:10:12 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 200 tests, 4 stderr failures, 0 stdout failures =================
memcheck/tests/mempool (stderr)
memcheck/tests/pointer-trace (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.21033/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c
source='m_scheduler/scheduler.c' object='scheduler.o' libtool=no \
depfile='.deps/scheduler.Po' tmpdepfile='.deps/scheduler.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.21033/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c
m_scheduler/scheduler.c: In function `name_of_sched_event':
m_scheduler/scheduler.c:153: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:153: (Each undeclared identifier is reported only once
m_scheduler/scheduler.c:153: for each function it appears in.)
m_scheduler/scheduler.c: In function `vgPlain_scheduler':
m_scheduler/scheduler.c:719: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:820: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
make[3]: *** [scheduler.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.21033/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.21033/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.21033/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Nov 4 03:15:09 2005
--- new.short Fri Nov 4 03:21:57 2005
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- depmode=gcc3 /bin/sh ../depcomp \
- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.21033/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c
- source='m_scheduler/scheduler.c' object='scheduler.o' libtool=no \
- depfile='.deps/scheduler.Po' tmpdepfile='.deps/scheduler.TPo' \
- depmode=gcc3 /bin/sh ../depcomp \
- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.21033/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c
- m_scheduler/scheduler.c: In function `name_of_sched_event':
- m_scheduler/scheduler.c:153: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:153: (Each undeclared identifier is reported only once
- m_scheduler/scheduler.c:153: for each function it appears in.)
- m_scheduler/scheduler.c: In function `vgPlain_scheduler':
- m_scheduler/scheduler.c:719: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:820: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
- make[3]: *** [scheduler.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.21033/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.21033/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.21033/valgrind'
- make: *** [all] Error 2
--- 3,14 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 200 tests, 4 stderr failures, 0 stdout failures =================
! memcheck/tests/mempool (stderr)
! memcheck/tests/pointer-trace (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
|
|
From: Tom H. <th...@cy...> - 2005-11-04 03:20:12
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-11-04 03:10:11 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 175 tests, 1 stderr failure, 1 stdout failure =================
none/tests/amd64/faultstatus (stderr)
none/tests/mremap2 (stdout)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
make[4]: Leaving directory `/tmp/valgrind.31167/valgrind/VEX'
gcc -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -m64 -Wa,-gstabs -Wno-long-long -c -o dispatch-amd64-linux.o `test -f 'm_dispatch/dispatch-amd64-linux.S' || echo './'`m_dispatch/dispatch-amd64-linux.S
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31167/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31167/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
m_scheduler/scheduler.c: In function 'name_of_sched_event':
m_scheduler/scheduler.c:153: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
m_scheduler/scheduler.c:153: error: for each function it appears in.)
m_scheduler/scheduler.c: In function 'vgPlain_scheduler':
m_scheduler/scheduler.c:719: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:820: error: 'VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
make[3]: *** [scheduler.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.31167/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.31167/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.31167/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Nov 4 03:14:53 2005
--- new.short Fri Nov 4 03:20:04 2005
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- make[4]: Leaving directory `/tmp/valgrind.31167/valgrind/VEX'
- gcc -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -m64 -Wa,-gstabs -Wno-long-long -c -o dispatch-amd64-linux.o `test -f 'm_dispatch/dispatch-amd64-linux.S' || echo './'`m_dispatch/dispatch-amd64-linux.S
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31167/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
- then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31167/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
- m_scheduler/scheduler.c: In function 'name_of_sched_event':
- m_scheduler/scheduler.c:153: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
- m_scheduler/scheduler.c:153: error: for each function it appears in.)
- m_scheduler/scheduler.c: In function 'vgPlain_scheduler':
- m_scheduler/scheduler.c:719: error: 'VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:820: error: 'VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
- make[3]: *** [scheduler.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.31167/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.31167/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.31167/valgrind'
- make: *** [all] Error 2
--- 3,12 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 175 tests, 1 stderr failure, 1 stdout failure =================
! none/tests/amd64/faultstatus (stderr)
! none/tests/mremap2 (stdout)
|
|
From: Tom H. <th...@cy...> - 2005-11-04 03:17:37
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-11-04 03:05:10 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 175 tests, 1 stderr failure, 1 stdout failure =================
none/tests/amd64/faultstatus (stderr)
none/tests/mremap2 (stdout)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
make[4]: Leaving directory `/tmp/valgrind.2763/valgrind/VEX'
gcc -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -m64 -Wa,-gstabs -Wno-long-long -c -o dispatch-amd64-linux.o `test -f 'm_dispatch/dispatch-amd64-linux.S' || echo './'`m_dispatch/dispatch-amd64-linux.S
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.2763/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.2763/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
m_scheduler/scheduler.c: In function `name_of_sched_event':
m_scheduler/scheduler.c:153: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
m_scheduler/scheduler.c:153: error: for each function it appears in.)
m_scheduler/scheduler.c: In function `vgPlain_scheduler':
m_scheduler/scheduler.c:719: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:820: error: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
make[3]: *** [scheduler.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.2763/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.2763/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.2763/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Nov 4 03:11:37 2005
--- new.short Fri Nov 4 03:17:32 2005
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- make[4]: Leaving directory `/tmp/valgrind.2763/valgrind/VEX'
- gcc -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -m64 -Wa,-gstabs -Wno-long-long -c -o dispatch-amd64-linux.o `test -f 'm_dispatch/dispatch-amd64-linux.S' || echo './'`m_dispatch/dispatch-amd64-linux.S
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.2763/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
- then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.2763/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
- m_scheduler/scheduler.c: In function `name_of_sched_event':
- m_scheduler/scheduler.c:153: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
- m_scheduler/scheduler.c:153: error: for each function it appears in.)
- m_scheduler/scheduler.c: In function `vgPlain_scheduler':
- m_scheduler/scheduler.c:719: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:820: error: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
- make[3]: *** [scheduler.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.2763/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.2763/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.2763/valgrind'
- make: *** [all] Error 2
--- 3,12 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 175 tests, 1 stderr failure, 1 stdout failure =================
! none/tests/amd64/faultstatus (stderr)
! none/tests/mremap2 (stdout)
|
|
From: Tom H. <th...@cy...> - 2005-11-04 03:12:04
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-11-04 03:00:04 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 175 tests, 2 stderr failures, 0 stdout failures =================
none/tests/amd64/faultstatus (stderr)
none/tests/fdleak_fcntl (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
make[4]: Leaving directory `/tmp/valgrind.28554/valgrind/VEX'
gcc -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -m64 -Wa,-gstabs -Wno-long-long -c -o dispatch-amd64-linux.o `test -f 'm_dispatch/dispatch-amd64-linux.S' || echo './'`m_dispatch/dispatch-amd64-linux.S
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.28554/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.28554/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
m_scheduler/scheduler.c: In function `name_of_sched_event':
m_scheduler/scheduler.c:153: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
m_scheduler/scheduler.c:153: error: for each function it appears in.)
m_scheduler/scheduler.c: In function `vgPlain_scheduler':
m_scheduler/scheduler.c:719: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
m_scheduler/scheduler.c:820: error: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
make[3]: *** [scheduler.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.28554/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.28554/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.28554/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Nov 4 03:01:24 2005
--- new.short Fri Nov 4 03:11:57 2005
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- make[4]: Leaving directory `/tmp/valgrind.28554/valgrind/VEX'
- gcc -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -m64 -Wa,-gstabs -Wno-long-long -c -o dispatch-amd64-linux.o `test -f 'm_dispatch/dispatch-amd64-linux.S' || echo './'`m_dispatch/dispatch-amd64-linux.S
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.28554/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT replacemalloc_core.o -MD -MP -MF ".deps/replacemalloc_core.Tpo" -c -o replacemalloc_core.o `test -f 'm_replacemalloc/replacemalloc_core.c' || echo './'`m_replacemalloc/replacemalloc_core.c; \
- then mv -f ".deps/replacemalloc_core.Tpo" ".deps/replacemalloc_core.Po"; else rm -f ".deps/replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.28554/Inst/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -m64 -fomit-frame-pointer -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -Wdeclaration-after-statement -MT scheduler.o -MD -MP -MF ".deps/scheduler.Tpo" -c -o scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/scheduler.Tpo" ".deps/scheduler.Po"; else rm -f ".deps/scheduler.Tpo"; exit 1; fi
- m_scheduler/scheduler.c: In function `name_of_sched_event':
- m_scheduler/scheduler.c:153: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:153: error: (Each undeclared identifier is reported only once
- m_scheduler/scheduler.c:153: error: for each function it appears in.)
- m_scheduler/scheduler.c: In function `vgPlain_scheduler':
- m_scheduler/scheduler.c:719: error: `VEX_TRC_JMP_SYSCALL' undeclared (first use in this function)
- m_scheduler/scheduler.c:820: error: `VEX_TRC_JMP_SYSENTER_X86' undeclared (first use in this function)
- make[3]: *** [scheduler.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.28554/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.28554/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.28554/valgrind'
- make: *** [all] Error 2
--- 3,12 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 175 tests, 2 stderr failures, 0 stdout failures =================
! none/tests/amd64/faultstatus (stderr)
! none/tests/fdleak_fcntl (stderr)
|