You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(31) |
2
(27) |
|
3
(25) |
4
(21) |
5
(21) |
6
(21) |
7
(32) |
8
(23) |
9
(15) |
|
10
(12) |
11
(9) |
12
(10) |
13
(10) |
14
(9) |
15
(7) |
16
(20) |
|
17
(14) |
18
(71) |
19
(67) |
20
(50) |
21
(25) |
22
(15) |
23
(37) |
|
24
(25) |
25
(41) |
26
(34) |
27
(57) |
28
(20) |
29
(30) |
30
(13) |
|
31
(18) |
|
|
|
|
|
|
|
From: John M. <tt...@te...> - 2005-07-25 14:37:11
|
Yo, I've attached a patch that wraps the inotify system calls on x86 linux. Please consider this for the next version of valgrind. Thanks, John McCutchan |
|
From: Nicholas N. <nj...@cs...> - 2005-07-25 12:50:38
|
On Mon, 25 Jul 2005, Josef Weidendorfer wrote: > Add: > - If there are any binary incompatible tool API changes against the last > stable release, increase VG_CORE_INTERFACE_VERSION in > include/pub_tool_tooliface.h. Done. > It would be nice to have some automated tests to help with this issue. True. Would you like to try writing one? (I can't see myself how exactly it would be formulated.) N |
|
From: <sv...@va...> - 2005-07-25 12:49:40
|
Author: njn Date: 2005-07-25 13:49:39 +0100 (Mon, 25 Jul 2005) New Revision: 4248 Log: Added a point for Josef W. Modified: trunk/docs/internals/release-HOWTO Modified: trunk/docs/internals/release-HOWTO =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/internals/release-HOWTO 2005-07-25 12:35:02 UTC (rev 4247) +++ trunk/docs/internals/release-HOWTO 2005-07-25 12:49:39 UTC (rev 4248) @@ -20,6 +20,9 @@ =20 - Add X.Y.Z and X.Y.Z.SVN versions to Bugzilla (ask Dirk to do it) =20 +- If there are any binary incompatible tool API changes against the last + stable release, ensure that VG_CORE_INTERFACE_VERSION in + include/pub_tool_tooliface.h has been increased since the last release= . =20 For each release candidate (should do release candidates for big release= s, bug-fix-only releases might not need one): |
|
From: <sv...@va...> - 2005-07-25 12:35:52
|
Author: de Date: 2005-07-25 13:35:02 +0100 (Mon, 25 Jul 2005) New Revision: 4247 Log: updated j's email address Modified: trunk/docs/xml/vg-entities.xml Modified: trunk/docs/xml/vg-entities.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/vg-entities.xml 2005-07-25 00:12:19 UTC (rev 4246) +++ trunk/docs/xml/vg-entities.xml 2005-07-25 12:35:02 UTC (rev 4247) @@ -1,6 +1,6 @@ <!-- misc. strings --> <!ENTITY vg-url "http://www.valgrind.org"> -<!ENTITY vg-jemail "js...@va..."> +<!ENTITY vg-jemail "ju...@va..."> <!ENTITY vg-vemail "val...@va..."> <!ENTITY vg-lifespan "2000-2005"> <!ENTITY vg-users-list "http://lists.sourceforge.net/lists/listinfo/valg= rind-users"> |
|
From: <sv...@va...> - 2005-07-25 11:58:43
|
Author: sewardj
Date: 2005-07-25 12:58:34 +0100 (Mon, 25 Jul 2005)
New Revision: 1299
Log:
Implement a couple of missing x87 insns.
Modified:
trunk/priv/guest-amd64/gdefs.h
trunk/priv/guest-amd64/ghelpers.c
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/gdefs.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/gdefs.h 2005-07-24 06:29:34 UTC (rev 1298)
+++ trunk/priv/guest-amd64/gdefs.h 2005-07-25 11:58:34 UTC (rev 1299)
@@ -92,7 +92,7 @@
ULong cc_dep1, ULong cc_dep2, ULong cc_ndep=20
);
=20
-//extern ULong amd64g_calculate_FXAM ( ULong tag, ULong dbl );
+extern ULong amd64g_calculate_FXAM ( ULong tag, ULong dbl );
=20
extern ULong amd64g_calculate_RCR (=20
ULong arg, ULong rot_amt, ULong rflags_in, Long sz=20
@@ -173,11 +173,17 @@
#define AMD64G_CC_MASK_P (1 << AMD64G_CC_SHIFT_P)
=20
/* FPU flag masks */
-#define AMD64G_FC_MASK_C3 (1 << 14)
-#define AMD64G_FC_MASK_C2 (1 << 10)
-#define AMD64G_FC_MASK_C1 (1 << 9)
-#define AMD64G_FC_MASK_C0 (1 << 8)
+#define AMD64G_FC_SHIFT_C3 14
+#define AMD64G_FC_SHIFT_C2 10
+#define AMD64G_FC_SHIFT_C1 9
+#define AMD64G_FC_SHIFT_C0 8
=20
+#define AMD64G_FC_MASK_C3 (1 << AMD64G_FC_SHIFT_C3)
+#define AMD64G_FC_MASK_C2 (1 << AMD64G_FC_SHIFT_C2)
+#define AMD64G_FC_MASK_C1 (1 << AMD64G_FC_SHIFT_C1)
+#define AMD64G_FC_MASK_C0 (1 << AMD64G_FC_SHIFT_C0)
+
+
/* %RFLAGS thunk descriptors. A four-word thunk is used to record
details of the most recent flag-setting operation, so the flags can
be computed later if needed. It is possible to do this a little
Modified: trunk/priv/guest-amd64/ghelpers.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/ghelpers.c 2005-07-24 06:29:34 UTC (rev 1298)
+++ trunk/priv/guest-amd64/ghelpers.c 2005-07-25 11:58:34 UTC (rev 1299)
@@ -1221,6 +1221,85 @@
/*--- Supporting functions for x87 FPU activities. ---*/
/*---------------------------------------------------------------*/
=20
+static inline Bool host_is_little_endian ( void )
+{
+ UInt x =3D 0x76543210;
+ UChar* p =3D (UChar*)(&x);
+ return toBool(*p =3D=3D 0x10);
+}
+
+/* Inspect a value and its tag, as per the x87 'FXAM' instruction. */
+/* CALLED FROM GENERATED CODE: CLEAN HELPER */
+ULong amd64g_calculate_FXAM ( ULong tag, ULong dbl )=20
+{
+ Bool mantissaIsZero;
+ Int bexp;
+ UChar sign;
+ UChar* f64;
+
+ vassert(host_is_little_endian());
+
+ /* vex_printf("calculate_FXAM ( %d, %llx ) .. ", tag, dbl ); */
+
+ f64 =3D (UChar*)(&dbl);
+ sign =3D toUChar( (f64[7] >> 7) & 1 );
+
+ /* First off, if the tag indicates the register was empty,
+ return 1,0,sign,1 */
+ if (tag =3D=3D 0) {
+ /* vex_printf("Empty\n"); */
+ return AMD64G_FC_MASK_C3 | 0 | (sign << AMD64G_FC_SHIFT_C1)=20
+ | AMD64G_FC_MASK_C0;
+ }
+
+ bexp =3D (f64[7] << 4) | ((f64[6] >> 4) & 0x0F);
+ bexp &=3D 0x7FF;
+
+ mantissaIsZero
+ =3D toBool(
+ (f64[6] & 0x0F) =3D=3D 0=20
+ && (f64[5] | f64[4] | f64[3] | f64[2] | f64[1] | f64[0]) =3D=3D=
0
+ );
+
+ /* If both exponent and mantissa are zero, the value is zero.
+ Return 1,0,sign,0. */
+ if (bexp =3D=3D 0 && mantissaIsZero) {
+ /* vex_printf("Zero\n"); */
+ return AMD64G_FC_MASK_C3 | 0=20
+ | (sign << AMD64G_FC_SHIFT_C1) | 0;
+ }
+ =20
+ /* If exponent is zero but mantissa isn't, it's a denormal.
+ Return 1,1,sign,0. */
+ if (bexp =3D=3D 0 && !mantissaIsZero) {
+ /* vex_printf("Denormal\n"); */
+ return AMD64G_FC_MASK_C3 | AMD64G_FC_MASK_C2=20
+ | (sign << AMD64G_FC_SHIFT_C1) | 0;
+ }
+
+ /* If the exponent is 7FF and the mantissa is zero, this is an infini=
ty.
+ Return 0,1,sign,1. */
+ if (bexp =3D=3D 0x7FF && mantissaIsZero) {
+ /* vex_printf("Inf\n"); */
+ return 0 | AMD64G_FC_MASK_C2 | (sign << AMD64G_FC_SHIFT_C1)=20
+ | AMD64G_FC_MASK_C0;
+ }
+
+ /* If the exponent is 7FF and the mantissa isn't zero, this is a NaN.
+ Return 0,0,sign,1. */
+ if (bexp =3D=3D 0x7FF && !mantissaIsZero) {
+ /* vex_printf("NaN\n"); */
+ return 0 | 0 | (sign << AMD64G_FC_SHIFT_C1) | AMD64G_FC_MASK_C0;
+ }
+
+ /* Uh, ok, we give up. It must be a normal finite number.
+ Return 0,1,sign,0.
+ */
+ /* vex_printf("normal\n"); */
+ return 0 | AMD64G_FC_MASK_C2 | (sign << AMD64G_FC_SHIFT_C1) | 0;
+}
+
+
// MAYBE NOT TRUE: /* CALLED FROM GENERATED CODE */
// MAYBE NOT TRUE: /* DIRTY HELPER (writes guest state) */
/* Initialise the x87 FPU state as per 'finit'. */
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-07-24 06:29:34 UTC (rev 1298)
+++ trunk/priv/guest-amd64/toIR.c 2005-07-25 11:58:34 UTC (rev 1299)
@@ -2394,8 +2394,7 @@
dependency. */
if ((op8 =3D=3D Iop_Xor8 || (op8 =3D=3D Iop_Sub8 && addSubCarry))
&& offsetIRegG(size,pfx,rm) =3D=3D offsetIRegE(size,pfx,rm)) {
- vassert(0); /* awaiting test case */
- if (op8 =3D=3D Iop_Sub8)
+ if (False && op8 =3D=3D Iop_Sub8)
vex_printf("vex amd64->IR: sbb %%r,%%r optimisation(1)\n");
putIRegG(size,pfx,rm, mkU(ty,0));
}
@@ -4602,25 +4601,25 @@
put_ST_UNCHECKED(0, unop(Iop_AbsF64, get_ST(0)));
break;
=20
-//.. case 0xE5: { /* FXAM */
-//.. /* This is an interesting one. It examines %st(0),
-//.. regardless of whether the tag says it's empty or =
not.
-//.. Here, just pass both the tag (in our format) and =
the
-//.. value (as a double, actually a ULong) to a helper
-//.. function. */
-//.. IRExpr** args
-//.. =3D mkIRExprVec_2( unop(Iop_8Uto32, get_ST_TAG(0)=
),
-//.. unop(Iop_ReinterpF64asI64,=20
-//.. get_ST_UNCHECKED(0)) );
-//.. put_C3210(mkIRExprCCall(
-//.. Ity_I32,=20
-//.. 0/*regparm*/,=20
-//.. "x86g_calculate_FXAM", &x86g_calculate_=
FXAM,
-//.. args
-//.. ));
-//.. DIP("fxam\n");
-//.. break;
-//.. }
+ case 0xE5: { /* FXAM */
+ /* This is an interesting one. It examines %st(0),
+ regardless of whether the tag says it's empty or not.
+ Here, just pass both the tag (in our format) and the
+ value (as a double, actually a ULong) to a helper
+ function. */
+ IRExpr** args
+ =3D mkIRExprVec_2( unop(Iop_8Uto64, get_ST_TAG(0)),
+ unop(Iop_ReinterpF64asI64,=20
+ get_ST_UNCHECKED(0)) );
+ put_C3210(mkIRExprCCall(
+ Ity_I64,=20
+ 0/*regparm*/,=20
+ "amd64g_calculate_FXAM", &amd64g_calculate_F=
XAM,
+ args
+ ));
+ DIP("fxam\n");
+ break;
+ }
=20
case 0xE8: /* FLD1 */
DIP("fld1\n");
@@ -5599,21 +5598,24 @@
fp_pop();
break;
=20
-//.. case 0xE0: /* FNSTSW %ax */
-//.. DIP("fnstsw %%ax\n");
-//.. /* Invent a plausible-looking FPU status word value =
and
-//.. dump it in %AX:
-//.. ((ftop & 7) << 11) | (c3210 & 0x4700)
-//.. */
-//.. putIReg(2, R_EAX,
-//.. unop(Iop_32to16,
-//.. binop(Iop_Or32,
-//.. binop(Iop_Shl32,=20
-//.. binop(Iop_And32, get_ftop(), mkU=
32(7)),=20
-//.. mkU8(11)),
-//.. binop(Iop_And32, get_C3210(), mkU32(0x=
4700))
-//.. )));
-//.. break;
+ case 0xE0: /* FNSTSW %ax */
+ DIP("fnstsw %%ax\n");
+ /* Invent a plausible-looking FPU status word value and
+ dump it in %AX:
+ ((ftop & 7) << 11) | (c3210 & 0x4700)
+ */
+ putIRegRAX(
+ 2,
+ unop(Iop_32to16,
+ binop(Iop_Or32,
+ binop(Iop_Shl32,=20
+ binop(Iop_And32, get_ftop(), mkU32(7)=
),=20
+ mkU8(11)),
+ binop(Iop_And32,=20
+ unop(Iop_64to32, get_C3210()),=20
+ mkU32(0x4700))
+ )));
+ break;
=20
case 0xE8 ... 0xEF: /* FUCOMIP %st(0),%st(?) */
fp_do_ucomi_ST0_STi( (UInt)modrm - 0xE8, True );
|
|
From: Josef W. <Jos...@gm...> - 2005-07-25 07:38:32
|
Hi, On Monday 25 July 2005 01:47, sv...@va... wrote: > +- Update version number and date in docs/xml/vg-entities.xml. (Exact > + release date probably won't be known yet, updating it is in the list > below + of tasks for the official release.) Add: - If there are any binary incompatible tool API changes against the last stable release, increase VG_CORE_INTERFACE_VERSION in include/pub_tool_tooliface.h. It would be nice to have some automated tests to help with this issue. Josef |
|
From: <js...@ac...> - 2005-07-25 02:51:35
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-07-25 03:30:00 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 179 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2005-07-25 02:45:07
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-07-25 04:40:00 CEST 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 == 154 tests, 100 stderr failures, 18 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree-2trace (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/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (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/overlap (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stdout) 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 (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/str_tester (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/with-space (stderr) memcheck/tests/writev (stderr) memcheck/tests/xml1 (stderr) memcheck/tests/zeropage (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stdout) cachegrind/tests/dlclose (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_creat (stderr) none/tests/fdleak_dup (stderr) none/tests/fdleak_dup2 (stderr) none/tests/fdleak_fcntl (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/fdleak_open (stderr) none/tests/fdleak_pipe (stderr) none/tests/fdleak_socketpair (stderr) none/tests/manythreads (stdout) none/tests/manythreads (stderr) none/tests/pending (stdout) none/tests/pending (stderr) none/tests/pth_atfork1 (stdout) none/tests/pth_atfork1 (stderr) none/tests/pth_blockedsig (stdout) none/tests/pth_blockedsig (stderr) none/tests/pth_cancel1 (stdout) none/tests/pth_cancel1 (stderr) none/tests/pth_cancel2 (stderr) none/tests/pth_cvsimple (stdout) none/tests/pth_cvsimple (stderr) none/tests/pth_exit (stderr) none/tests/pth_once (stdout) none/tests/pth_once (stderr) none/tests/pth_stackalign (stdout) none/tests/pth_stackalign (stderr) none/tests/rcrl (stdout) none/tests/rcrl (stderr) none/tests/res_search (stdout) none/tests/res_search (stderr) none/tests/thread-exits (stdout) none/tests/thread-exits (stderr) none/tests/threaded-fork (stdout) none/tests/threaded-fork (stderr) none/tests/threadederrno (stdout) none/tests/threadederrno (stderr) none/tests/tls (stdout) none/tests/tls (stderr) |
|
From: Tom H. <to...@co...> - 2005-07-25 02:41:28
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-07-25 03:30:04 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 181 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-07-25 02:27:10
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-07-25 03:15:04 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 180 tests, 14 stderr failures, 0 stdout failures ================= 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/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-07-25 02:19:36
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-07-25 03:10:09 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 159 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) |
|
From: Tom H. <th...@cy...> - 2005-07-25 02:16:32
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-07-25 03:05:12 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 159 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) |
|
From: Tom H. <th...@cy...> - 2005-07-25 02:13:23
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-07-25 03:00:04 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 159 tests, 7 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) |
|
From: Julian S. <js...@ac...> - 2005-07-25 00:55:30
|
> Update docs for 3.0.0 release. Still to do: update command line options. Great stuff. Thanks for that. J |
|
From: Nicholas N. <nj...@cs...> - 2005-07-25 00:19:51
|
On Sat, 23 Jul 2005, Tom Hughes wrote: >>> You don't have to precompile them, just make sure you use -gstabs >>> or -gstabs+ when building them to force stabs debugging. >> >> That's true, but that would then expose you to the vagaries of whatever >> the compiler in question decided to emit into the stabs, which would mean >> it wasn't really clear what was being tested. > > Putting the assembly output from the compiler in is another option > as that preserves the stabs that the compiler generated whilst still > being text. That said subversion should handle binary files better. These are interesting ideas, and beyond what I intended... I was just thinking of retaining all the C tests, but having one or two binaries (or shared objects) containing examples of weird stabs stuff that has caused problems. This would be platform-specific, which is one reason against over-using it. N |
|
From: <sv...@va...> - 2005-07-25 00:12:26
|
Author: njn
Date: 2005-07-25 01:12:19 +0100 (Mon, 25 Jul 2005)
New Revision: 4246
Log:
Update docs for 3.0.0 release. Still to do: update command line options=
.
Modified:
trunk/docs/xml/dist-docs.xml
trunk/docs/xml/manual-core.xml
trunk/docs/xml/manual-intro.xml
trunk/docs/xml/quick-start-guide.xml
trunk/docs/xml/vg-entities.xml
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/docs/xml/dist-docs.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/xml/dist-docs.xml 2005-07-24 23:47:01 UTC (rev 4245)
+++ trunk/docs/xml/dist-docs.xml 2005-07-25 00:12:19 UTC (rev 4246)
@@ -61,21 +61,22 @@
</literallayout>
</chapter>
=20
- <chapter id=3D"dist.readme-packagers"=20
- xreflabel=3D"Readme Packagers">
- <title>README_PACKAGERS</title>
+ <chapter id=3D"dist.readme-developers"=20
+ xreflabel=3D"Readme Developer">
+ <title>README_DEVELOPERS</title>
<literallayout>
- <xi:include href=3D"../../README_PACKAGERS"=20
+ <xi:include href=3D"../../README_DEVELOPERS"=20
parse=3D"text"=20
xmlns:xi=3D"http://www.w3.org/2001/XInclude" />
</literallayout>
</chapter>
=20
- <chapter id=3D"dist.todo" xreflabel=3D"Todo">
- <title>TODO</title>
+ <chapter id=3D"dist.readme-packagers"=20
+ xreflabel=3D"Readme Packagers">
+ <title>README_PACKAGERS</title>
<literallayout>
- <xi:include href=3D"../../TODO"=20
- parse=3D"text" =20
+ <xi:include href=3D"../../README_PACKAGERS"=20
+ parse=3D"text"=20
xmlns:xi=3D"http://www.w3.org/2001/XInclude" />
</literallayout>
</chapter>
Modified: trunk/docs/xml/manual-core.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/manual-core.xml 2005-07-24 23:47:01 UTC (rev 4245)
+++ trunk/docs/xml/manual-core.xml 2005-07-25 00:12:19 UTC (rev 4246)
@@ -30,13 +30,16 @@
<programlisting><![CDATA[
valgrind --tool=3Dmemcheck ls -l]]></programlisting>
=20
+<para>(Memcheck is the default, so if you want to use it you can
+actually omit the <computeroutput>--tool</computeroutput> flag.</para>
+
<para>Regardless of which tool is in use, Valgrind takes control
of your program before it starts. Debugging information is read
from the executable and associated libraries, so that error
messages and other outputs can be phrased in terms of source code
locations (if that is appropriate).</para>
=20
-<para>Your program is then run on a synthetic x86 CPU provided by
+<para>Your program is then run on a synthetic CPU provided by
the Valgrind core. As new code is executed for the first time,
the core hands the code to the selected tool. The tool adds its
own instrumentation code to this and hands the result back to the
@@ -204,6 +207,13 @@
<computeroutput>.pid12345</computeroutput>part, you can instead use
<computeroutput>--log-file-exactly=3Dfilename</computeroutput>.
</para>
+
+ <para>You can also use the
+ <computeroutput>--log-file-qualifier=3D<VAR></computeroutput> o=
ption
+ to specify the filename via the environment variable
+ <computeroutput>$VAR</computeroutput>. This is rarely needed, but
+ very useful in certain circumstances (eg. when running MPI programs).
+ </para>
</listitem>
=20
<listitem id=3D"manual-core.out2socket"=20
@@ -644,6 +654,24 @@
</listitem>
=20
<listitem>
+ <para><computeroutput>--log-file-exactly=3D<filename></compute=
routput></para>
+ <para>Just like <computeroutput>--log-file</computeroutput>, but
+ the ".pid" suffix is not added. If you trace multiple processes
+ with Valgrind when using this option the log file may get all messed
+ up.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><computeroutput>--log-file-qualifer=3D<VAR></computerout=
put></para>
+ <para>Specifies that Valgrind should send all of its messages
+ to the file named by the environment variable
+ <computeroutput>$VAR</computeroutput>. This is useful when running
+ MPI programs.
+ </para>
+ </listitem>
+
+ <listitem>
<para><computeroutput>--log-socket=3D<ip-address:port-number><=
/computeroutput></para>
<para>Specifies that Valgrind should send all of its messages
to the specified port at the specified IP address. The port
@@ -901,7 +929,7 @@
<computeroutput>malloc</computeroutput>,
<computeroutput>realloc</computeroutput>, etc, return 8-byte
aligned addresses. This is standard for
- x86 processors. Some programs might however assume that
+ most processors. Some programs might however assume that
<computeroutput>malloc</computeroutput> et al return 16- or
more aligned memory. The supplied value must be between 4
and 4096 inclusive, and must be a power of two.</para>
@@ -994,7 +1022,9 @@
address space. This prevents stray writes from damaging
Valgrind itself. On x86, this uses the CPU's segmentation
machinery, and has almost no performance cost; there's almost
- never a reason to turn it off.</para>
+ never a reason to turn it off. On the other architectures this=20
+ option is currently ignored as they don't have a cheap way of achiev=
ing
+ the same functionality.</para>
</listitem>
=20
</itemizedlist>
@@ -1014,7 +1044,7 @@
<para><computeroutput>--single-step=3Dno</computeroutput>
[default]</para>
<para><computeroutput>--single-step=3Dyes</computeroutput></para>
- <para>When enabled, each x86 insn is translated separately
+ <para>When enabled, each instruction is translated separately
into instrumented code. When disabled, translation is done
on a per-basic-block basis, giving much better
translations. This option is very useful if your program expects
@@ -1116,7 +1146,7 @@
translation of the basic block containing the <number>'th
error context. When used with
<computeroutput>--single-step=3Dyes</computeroutput>, can show
- the exact x86 instruction causing an error. This is all
+ the exact instruction causing an error. This is all
fairly dodgy and doesn't work at all if threads are
involved.</para>
</listitem>
@@ -1431,6 +1461,23 @@
Getting this to work was technically challenging but it all works
well enough for significant threaded applications to work.</para>
=20
+<para>The main thing to point out is that although Valgrind works
+with the built-in threads system (eg. NPTL or LinuxThreads), it
+serialises execution so that only one thread is running at a time. This
+approach avoids the horrible implementation problems of implementing a
+truly multiprocessor version of Valgrind, but it does mean that threaded
+apps run only on one CPU, even if you have a multiprocessor
+machine.</para>
+
+<para>Valgrind schedules your program's threads in a round-robin fashion=
,
+with all threads having equal priority. It switches threads
+every 50000 basic blocks (on x86, typically around 300000
+instructions), which means you'll get a much finer interleaving
+of thread executions than when run natively. This in itself may
+cause your program to behave differently if you have some kind of
+concurrency, critical race, locking, or similar, bugs.</para>
+
+<!--
<para>It works as follows: threaded apps are (dynamically) linked
against <literal>libpthread.so</literal>. Usually this is the
one installed with your Linux distribution. Valgrind, however,
@@ -1464,7 +1511,7 @@
=20
<para>Valgrind schedules your threads in a round-robin fashion,
with all threads having equal priority. It switches threads
-every 50000 basic blocks (typically around 300000 x86
+every 50000 basic blocks (on x86, typically around 300000
instructions), which means you'll get a much finer interleaving
of thread executions than when run natively. This in itself may
cause your program to behave differently if you have some kind of
@@ -1498,7 +1545,7 @@
<literal>pthread_kill</literal>, <literal>sigwait</literal>
and <literal>raise</literal> are now implemented. Each thread
has its own signal mask, as POSIX requires. It's a bit
- kludgey -- there's a system-wide pending signal set, rather
+ kludgey - there's a system-wide pending signal set, rather
than one for each thread. But hey.</para>
</listitem>
=20
@@ -1512,6 +1559,7 @@
7.2. Also Mozilla 1.0RC2. OpenOffice 1.0. MySQL 3.something
(the current stable release).</para>
</formalpara>
+-->
=20
</sect1>
=20
@@ -1546,20 +1594,22 @@
<computeroutput>make</computeroutput>, <computeroutput>make
install</computeroutput> mechanism, and we have attempted to
ensure that it works on machines with kernel 2.4 or 2.6 and glibc
-2.2.X or 2.3.X.</para>
+2.2.X, 2.3.X, 2.4.X.</para>
=20
<para>There are two options (in addition to the usual
<computeroutput>--prefix=3D</computeroutput> which affect how Valgrind i=
s built:
<itemizedlist>
<listitem>
<para><computeroutput>--enable-pie</computeroutput></para>
- <para>>PIE stands for "position-independent executable". This is
- enabled by default if your toolchain supports it. PIE allows Valgrind
- to place itself as high as possible in memory, giving your program as
- much address space as possible. It also allows Valgrind to run under
- itself. If PIE is disabled, Valgrind loads at a default address which
- is suitable for most systems. This is also useful for debugging
- Valgrind itself.</para>
+ <para>PIE stands for "position-independent executable".
+ PIE allows Valgrind to place itself as high as possible in memory,
+ giving your program as much address space as possible. It also allows
+ Valgrind to run under itself. If PIE is disabled, Valgrind loads at a
+ default address which is suitable for most systems. This is also
+ useful for debugging Valgrind itself. It's not on by default because
+ it caused problems for some people. Note that not all toolchaines
+ support PIEs, you need fairly recent version of the compiler, linker,
+ etc.</para>
</listitem>
=20
<listitem>
@@ -1606,11 +1656,11 @@
them. If one of these breaks, please mail us!</para>
=20
<para>If you get an assertion failure on the expression
-<computeroutput>chunkSane(ch)</computeroutput> in
-<computeroutput>vg_free()</computeroutput> in
-<filename>vg_malloc.c</filename>, this may have happened because
+<computeroutput>blockSane(ch)</computeroutput> in
+<computeroutput>VG_(free)()</computeroutput> in
+<filename>m_mallocfree.c</filename>, this may have happened because
your program wrote off the end of a malloc'd block, or before its
-beginning. Valgrind should have emitted a proper message to that
+beginning. Valgrind hopefully will have emitted a proper message to tha=
t
effect before dying in this way. This is a known problem which
we should fix.</para>
=20
@@ -1628,15 +1678,14 @@
<para>The following list of limitations seems depressingly long.
However, most programs actually work fine.</para>
=20
-<para>Valgrind will run x86-GNU/Linux ELF dynamically linked
+<para>Valgrind will run x86/Linux ELF dynamically linked
binaries, on a kernel 2.4.X or 2.6.X system, subject to
the following constraints:</para>
=20
<itemizedlist>
-
<listitem>
- <para>No support for 3DNow instructions. If the translator
- encounters these, Valgrind will generate a SIGILL when the
+ <para>On x86 and AMD64, there is no support for 3DNow! instructions. =
If
+ the translator encounters these, Valgrind will generate a SIGILL when=
the
instruction is executed.</para>
</listitem>
=20
@@ -1647,15 +1696,6 @@
</listitem>
=20
<listitem>
- <para>Memcheck assumes that the floating point registers are
- not used as intermediaries in memory-to-memory copies, so it
- immediately checks definedness of values loaded from memory by
- floating-point loads. If you want to write code which copies
- around possibly-uninitialised values, you must ensure these
- travel through the integer registers, not the FPU.</para>
- </listitem>
-
- <listitem>
<para>If your program does its own memory management, rather
than using malloc/new/free/delete, it should still work, but
Valgrind's error checking won't be so effective. If you
@@ -1676,17 +1716,7 @@
</listitem>
=20
<listitem>
- <para>Programs which switch stacks are not well handled.
- Valgrind does have support for this, but I don't have great
- faith in it. It's difficult -- there's no cast-iron way to
- decide whether a large change in %esp is as a result of the
- program switching stacks, or merely allocating a large object
- temporarily on the current stack -- yet Valgrind needs to
- handle the two situations differently.</para>
- </listitem>
-
- <listitem>
- <para>x86 instructions, and system calls, have been
+ <para>Machine instructions, and system calls, have been
implemented on demand. So it's possible, although unlikely,
that a program will fall over with a message to that effect.
If this happens, please report ALL the details printed out, so
@@ -1694,12 +1724,6 @@
</listitem>
=20
<listitem>
- <para>x86 floating point works correctly, but floating-point
- code may run even more slowly than integer code, due to my
- simplistic approach to FPU emulation.</para>
- </listitem>
-
- <listitem>
<para>Memory consumption of your program is majorly increased
whilst running under Valgrind. This is due to the large
amount of administrative information maintained behind the
@@ -1712,18 +1736,88 @@
=20
<listitem>
<para>Valgrind can handle dynamically-generated code just
- fine. However, if you regenerate code over the top of old code
- (ie. at the same memory addresses) Valgrind will not realise
- the code has changed, and will run its old translations, which
- will be out-of-date. You need to use the
- VALGRIND_DISCARD_TRANSLATIONS client request in that case. For
- the same reason gcc's <ulink
- url=3D"http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html">tramp=
olines
- for nested functions</ulink> are currently unsupported, see
- <ulink url=3D"http://bugs.kde.org/show_bug.cgi?id=3D69511">bug
- 69511</ulink>.</para>
+ fine. If you regenerate code over the top of old code
+ (ie. at the same memory addresses), if the code is on the stack Valgr=
ind
+ will realise the code has changed, and work correctly. This is neces=
sary
+ to handle the trampolines GCC uses to implemented nested functions.
+ If you regenerate code somewhere other than the stack, you will need =
to
+ use the <computeroutput>--smc-check=3Dall</computeroutput> flag, and
+ Valgrind will run more slowly than normal.</para>
</listitem>
=20
+ <listitem>
+ <para>As of version 3.0.0, Valgrind has the following limitations
+ in its implementation of floating point relative to the IEEE754 stand=
ard.
+ </para>
+
+ <para>Precision: There is no support for 80 bit arithmetic.
+ Internally, Valgrind represents all FP numbers in 64 bits, and so
+ there may be some differences in results. Whether or not this is
+ critical remains to be seen. Note, the x86/amd64 fldt/fstpt
+ instructions (read/write 80-bit numbers) are correctly simulated,
+ using conversions to/from 64 bits, so that in-memory images of
+ 80-bit numbers look correct if anyone wants to see.</para>
+
+ <para>The impression observed from many FP regression tests is that
+ the accuracy differences aren't significant. Generally speaking, if
+ a program relies on 80-bit precision, there may be difficulties
+ porting it to non x86/amd64 platforms which only support 64-bit FP
+ precision. Even on x86/amd64, the program may get different results
+ depending on whether it is compiled to use SSE2 instructions
+ (64-bits only), or x87 instructions (80-bit). The net effect is to
+ make FP programs behave as if they had been run on a machine with
+ 64-bit IEEE floats, for example PowerPC. On amd64 FP arithmetic is
+ done by default on SSE2, so amd64 looks more like PowerPC than x86
+ from an FP perspective, and there are far fewer noticable accuracy
+ differences than with x86.</para>
+
+ <para>Rounding: Valgrind does observe the 4 IEEE-mandated rounding
+ modes (to nearest, to +infinity, to -infinity, to zero) for the
+ following conversions: float to integer, integer to float where
+ there is a possibility of loss of precision, and float-to-float
+ rounding. For all other FP operations, only the IEEE default mode
+ (round to nearest) is supported.</para>
+
+ <para>Numeric exceptions in FP code: IEEE754 defines five types of
+ numeric exception that can happen: invalid operation (sqrt of
+ negative number, etc), division by zero, overflow, underflow,
+ inexact (loss of precision).</para>
+
+ <para>For each exception, two courses of action are defined by 754:
+ either (1) a user-defined exception handler may be called, or (2) a
+ default action is defined, which "fixes things up" and allows the
+ computation to proceed without throwing an exception.</para>
+
+ <para>Currently Valgrind only supports the default fixup actions.
+ Again, feedback on the importance of exception support would be
+ appreciated.</para>
+
+ <para>When Valgrind detects that the program is trying to exceed any
+ of these limitations (setting exception handlers, rounding mode, or
+ precision control), it can print a message giving a traceback of
+ where this has happened, and continue execution. This behaviour
+ used to be the default, but the messages are annoying and so showing
+ them is now optional. Use
+ <computeroutput>--show-emwarns=3Dyes</computeroutput> to see
+ them.</para>
+
+ <para>The above limitations define precisely the IEEE754 'default'
+ behaviour: default fixup on all exceptions, round-to-nearest
+ operations, and 64-bit precision.</para>
+ </listitem>
+ =20
+ <listitem>
+ <para>As of version 3.0.0, Valgrind has the following limitations
+ in its implementation of x86/AMD64 SSE2 FP arithmetic.</para>
+
+ <para>Essentially the same: no exceptions, and limited observance
+ of rounding mode. Also, SSE2 has control bits which make it treat
+ denormalised numbers as zero (DAZ) and a related action, flush
+ denormals to zero (FTZ). Both of these cause SSE2 arithmetic to be
+ less accurate than IEEE requires. Valgrind detects, ignores, and
+ can warn about, attempts to enable either mode.</para>
+ </listitem>
+
</itemizedlist>
=20
=20
@@ -1756,7 +1850,9 @@
<para>Some gory details, for those with a passion for gory
details. You don't need to read this section if all you want to
do is use Valgrind. What follows is an outline of the machinery.
-A more detailed (and somewhat out of date) description is to be
+It is out of date, as the JITter has been completey rewritten in
+version 3.0, and so it works quite differently.
+A more detailed (and even more out of date) description is to be
found <xref linkend=3D"mc-tech-docs"/>.</para>
=20
<sect2 id=3D"manual-core.startb" xreflabel=3D"Getting Started">
Modified: trunk/docs/xml/manual-intro.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/manual-intro.xml 2005-07-24 23:47:01 UTC (rev 4245)
+++ trunk/docs/xml/manual-intro.xml 2005-07-25 00:12:19 UTC (rev 4246)
@@ -9,8 +9,8 @@
<title>An Overview of Valgrind</title>
=20
<para>Valgrind is a flexible system for debugging and profiling
-Linux-x86 executables. The system consists of a core, which
-provides a synthetic x86 CPU in software, and a series of tools,
+Linux executables. The system consists of a core, which
+provides a synthetic CPU in software, and a series of tools,
each of which performs some kind of debugging, profiling, or
similar task. The architecture is modular, so that new tools can
be created easily and without disturbing the existing
@@ -101,10 +101,10 @@
of cache misses, memory references and instructions accruing
to each line of source code, with per-function, per-module
and whole-program summaries. If you ask really nicely it
- will even show counts for each individual x86
+ will even show counts for each individual machine
instruction.</para>
=20
- <para>Cachegrind auto-detects your machine's cache
+ <para>On x86 and AMD64, Cachegrind auto-detects your machine's cache
configuration using the
<computeroutput>CPUID</computeroutput> instruction, and so
needs no further configuration info, in most cases.</para>
@@ -146,19 +146,22 @@
illustrate how to create simple tools and to help the valgrind
developers in various ways.</para>
=20
-<para>Valgrind is closely tied to details of the CPU, operating
-system and to a less extent, compiler and basic C libraries. This
-makes it difficult to make it portable, so we have chosen at the
-outset to concentrate on what we believe to be a widely used
-platform: Linux on x86s. Valgrind uses the standard Unix
+<para>Valgrind is closely tied to details of the CPU and operating
+system, and to a lesser extent, the compiler and basic C libraries.
+Nonetheless, as of version 3.0.0 it supports several platforms: x86/Lin=
ux
+(mature), AMD64/Linux (immature but works well), and PPC32/Linux (very
+preliminary). Valgrind uses the standard Unix
<computeroutput>./configure</computeroutput>,
<computeroutput>make</computeroutput>, <computeroutput>make
install</computeroutput> mechanism, and we have attempted to
ensure that it works on machines with kernel 2.4 or 2.6 and glibc
-2.1.X--2.3.X.</para>
+2.2.X--2.4.X.</para>
=20
<para>Valgrind is licensed under the <xref linkend=3D"license.gpl"/>,
-version 2. The <computeroutput>valgrind/*.h</computeroutput> headers ar=
e
+version 2. The <computeroutput>valgrind/*.h</computeroutput> headers th=
at
+you may wish to include in your code (eg.
+<computeroutput>valgrind.h</computeroutput>,
+<computeroutput>memcheck.h</computeroutput>) are
distributed under a BSD-style license, so you may include them in your c=
ode
without worrying about license conflicts. Some of the PThreads test cas=
es,
<computeroutput>pth_*.c</computeroutput>, are taken from
Modified: trunk/docs/xml/quick-start-guide.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/quick-start-guide.xml 2005-07-24 23:47:01 UTC (rev 424=
5)
+++ trunk/docs/xml/quick-start-guide.xml 2005-07-25 00:12:19 UTC (rev 424=
6)
@@ -12,8 +12,9 @@
=20
<title>Valgrind Quick Start Guide</title>
=20
-<para>The Valgrind distribution has multiple tools. The memory checking
-tool (called Memcheck) can detect many common memory errors such as:
+<para>The Valgrind distribution has multiple tools. The most popular is=
the
+memory checking tool (called Memcheck) which can detect many common memo=
ry
+errors such as:
</para>
=20
<itemizedlist>
@@ -31,8 +32,8 @@
=20
<para>What follows is the minimum information you need to start detectin=
g
memory errors in your program with Memcheck. Note that this guide appli=
es
-to Valgrind version 2.4.0; some of the information is not quite right f=
or
-earlier versions.</para>
+to Valgrind version 2.4.0 and later; some of the information is not qui=
te
+right for earlier versions.</para>
=20
<sect1 id=3D"quick-start.prepare"=20
xreflabel=3D"Preparing your program">
@@ -58,8 +59,8 @@
</programlisting>
=20
Memcheck is the default tool. The
-<computeroutput>--leak-check</computeroutput> option turns on the memory
-leak detector.</para>
+<computeroutput>--leak-check</computeroutput> option turns on the detail=
ed
+memory leak detector.</para>
=20
<para>Your program will run much slower (eg. 20 to 30 times) than normal=
,
and use a lot more memory. Memcheck will issue messages about memory er=
rors
@@ -169,7 +170,7 @@
</itemizedlist>
=20
If you don't understand an error message, please consult
-<xref linkend=3D"mc-manual.flags"/> in the <xref linkend=3D"manual"/> wh=
ich has
+<xref linkend=3D"mc-manual.errormsgs"/> in the <xref linkend=3D"manual"/=
> which has
examples of all the error messages Memcheck produces.</para>
</sect1>
=20
Modified: trunk/docs/xml/vg-entities.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/xml/vg-entities.xml 2005-07-24 23:47:01 UTC (rev 4245)
+++ trunk/docs/xml/vg-entities.xml 2005-07-25 00:12:19 UTC (rev 4246)
@@ -6,7 +6,7 @@
<!ENTITY vg-users-list "http://lists.sourceforge.net/lists/listinfo/valg=
rind-users">
=20
<!-- valgrind release + version stuff -->
-<!ENTITY rel-type "Development release">
+<!ENTITY rel-type "Release">
<!ENTITY rel-version "3.0.0">
-<!ENTITY rel-date "June 01 2005">
+<!ENTITY rel-date "July 24 2005">
=20
Modified: trunk/memcheck/docs/mc-manual.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/docs/mc-manual.xml 2005-07-24 23:47:01 UTC (rev 4245)
+++ trunk/memcheck/docs/mc-manual.xml 2005-07-25 00:12:19 UTC (rev 4246)
@@ -17,7 +17,7 @@
<para>Memcheck is Valgrind-1.0.X's checking mechanism bundled up
into a tool. All reads and writes of memory are checked, and
calls to malloc/new/free/delete are intercepted. As a result,
-memcheck can detect the following problems:</para>
+Memcheck can detect the following problems:</para>
=20
<itemizedlist>
<listitem>
@@ -56,8 +56,8 @@
=20
=20
<sect1 id=3D"mc-manual.flags"=20
- xreflabel=3D"Command-line flags specific to memcheck">
-<title>Command-line flags specific to memcheck</title>
+ xreflabel=3D"Command-line flags specific to Memcheck">
+<title>Command-line flags specific to Memcheck</title>
=20
<itemizedlist id=3D"leakcheck">
<listitem>
@@ -178,7 +178,7 @@
<para><computeroutput>--avoid-strlen-errors=3Dyes</computeroutput> [=
default]</para>
<para>Enable or disable a heuristic for dealing with highly-optimize=
d=20
versions of strlen. These versions of strlen can cause spurious err=
ors=20
- to be reported by memcheck, so it's usually a good idea to leave thi=
s
+ to be reported by Memcheck, so it's usually a good idea to leave thi=
s
enabled.</para>
</listitem>
=20
|