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
(32) |
2
(22) |
3
(47) |
4
(29) |
5
(18) |
6
(16) |
|
7
(21) |
8
(29) |
9
(23) |
10
(68) |
11
(20) |
12
(17) |
13
(17) |
|
14
(27) |
15
(26) |
16
(21) |
17
(13) |
18
(19) |
19
(29) |
20
(13) |
|
21
(9) |
22
(8) |
23
(29) |
24
(56) |
25
(21) |
26
(46) |
27
(33) |
|
28
(25) |
29
(41) |
30
(35) |
31
(28) |
|
|
|
|
From: <sv...@va...> - 2005-08-30 02:33:23
|
Author: njn
Date: 2005-08-30 03:33:22 +0100 (Tue, 30 Aug 2005)
New Revision: 4579
Log:
add an item about creating branches when necessary
Modified:
trunk/docs/internals/release-HOWTO.txt
Modified: trunk/docs/internals/release-HOWTO.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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.txt 2005-08-30 02:33:09 UTC (rev 4=
578)
+++ trunk/docs/internals/release-HOWTO.txt 2005-08-30 02:33:22 UTC (rev 4=
579)
@@ -87,7 +87,9 @@
- Check tarball builds, installs, regtests on platforms of interest.
If not, fix and repeat until success.
=20
-- Tag the repository ("VALGRIND_X_Y_Z").
+- Tag the repositories ("VALGRIND_X_Y_Z" and "VEX_X_Y_Z").
+ If it's a X.Y.0 release, make "VALGRIND_X_Y_BRANCH" and "VEX_X_Y_BRANC=
H"
+ branches too.
=20
- Update website:=20
- Put the tarball up.
|
|
From: <sv...@va...> - 2005-08-30 02:33:11
|
Author: sewardj Date: 2005-08-30 03:33:09 +0100 (Tue, 30 Aug 2005) New Revision: 4578 Log: Point the vex external here to VEX_3_0_1. Modified: tags/VALGRIND_3_0_1/ Property changes on: tags/VALGRIND_3_0_1 ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/branches/VEX_3_0_BRANCH + VEX svn://svn.valgrind.org/vex/tags/VEX_3_0_1 |
|
From: <sv...@va...> - 2005-08-30 02:29:45
|
Author: sewardj Date: 2005-08-30 03:29:42 +0100 (Tue, 30 Aug 2005) New Revision: 1368 Log: Tag vex for Valgrind 3.0.1. Added: tags/VEX_3_0_1/ Copied: tags/VEX_3_0_1 (from rev 1367, branches/VEX_3_0_BRANCH) |
|
From: Tom H. <th...@cy...> - 2005-08-30 02:28:28
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-08-30 03:15:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 186 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: <sv...@va...> - 2005-08-30 02:28:03
|
Author: sewardj Date: 2005-08-30 03:27:58 +0100 (Tue, 30 Aug 2005) New Revision: 4577 Log: Tag valgrind 3.0.1. Added: tags/VALGRIND_3_0_1/ Copied: tags/VALGRIND_3_0_1 (from rev 4575, branches/VALGRIND_3_0_BRANCH) |
|
From: Tom H. <th...@cy...> - 2005-08-30 02:24:32
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-08-30 03:10:06 BST 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 == 186 tests, 2 stderr failures, 1 stdout failure ================= none/tests/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 ... done Running regression tests ... failed Regression test results follow == 186 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 30 03:17:55 2005 --- new.short Tue Aug 30 03:24:24 2005 *************** *** 8,12 **** ! == 186 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) --- 8,13 ---- ! == 186 tests, 2 stderr failures, 1 stdout failure ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) + none/tests/x86/yield (stdout) |
|
From: Tom H. <th...@cy...> - 2005-08-30 02:19:57
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-08-30 03:10:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 164 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: <sv...@va...> - 2005-08-30 02:17:31
|
Author: njn
Date: 2005-08-30 03:17:23 +0100 (Tue, 30 Aug 2005)
New Revision: 4576
Log:
Moved sched_* from "generic" to "linux"; Darwin doesn't have them.
Modified:
trunk/coregrind/m_syswrap/priv_syswrap-generic.h
trunk/coregrind/m_syswrap/priv_syswrap-linux.h
trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c
trunk/coregrind/m_syswrap/syswrap-x86-linux.c
Modified: trunk/coregrind/m_syswrap/priv_syswrap-generic.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/coregrind/m_syswrap/priv_syswrap-generic.h 2005-08-30 01:53:54 =
UTC (rev 4575)
+++ trunk/coregrind/m_syswrap/priv_syswrap-generic.h 2005-08-30 02:17:23 =
UTC (rev 4576)
@@ -110,14 +110,6 @@
DECL_TEMPLATE(generic, sys_munlock);
DECL_TEMPLATE(generic, sys_mlockall);
DECL_TEMPLATE(generic, sys_munlockall);
-DECL_TEMPLATE(generic, sys_sched_setparam);
-DECL_TEMPLATE(generic, sys_sched_getparam);
-DECL_TEMPLATE(generic, sys_sched_rr_get_interval);
-DECL_TEMPLATE(generic, sys_sched_setscheduler);
-DECL_TEMPLATE(generic, sys_sched_getscheduler);
-DECL_TEMPLATE(generic, sys_sched_yield);
-DECL_TEMPLATE(generic, sys_sched_get_priority_max);
-DECL_TEMPLATE(generic, sys_sched_get_priority_min);
DECL_TEMPLATE(generic, sys_nanosleep);
DECL_TEMPLATE(generic, sys_mremap); // POSIX, but Linux arg order may=
be odd
DECL_TEMPLATE(generic, sys_getuid);
@@ -209,8 +201,6 @@
DECL_TEMPLATE(generic, sys_mincore); // * L?
DECL_TEMPLATE(generic, sys_getdents64); // * (SVr4,SVID?)
DECL_TEMPLATE(generic, sys_fcntl64); // * P?
-DECL_TEMPLATE(generic, sys_sched_setaffinity); // * L?
-DECL_TEMPLATE(generic, sys_sched_getaffinity); // * L?
DECL_TEMPLATE(generic, sys_lookup_dcookie); // (*/32/64) L
DECL_TEMPLATE(generic, sys_statfs64); // * (?)
DECL_TEMPLATE(generic, sys_fstatfs64); // * (?)
Modified: trunk/coregrind/m_syswrap/priv_syswrap-linux.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/coregrind/m_syswrap/priv_syswrap-linux.h 2005-08-30 01:53:54 UT=
C (rev 4575)
+++ trunk/coregrind/m_syswrap/priv_syswrap-linux.h 2005-08-30 02:17:23 UT=
C (rev 4576)
@@ -149,6 +149,18 @@
DECL_TEMPLATE(linux, sys_removexattr);
DECL_TEMPLATE(linux, sys_lremovexattr);
DECL_TEMPLATE(linux, sys_fremovexattr);
+
+DECL_TEMPLATE(linux, sys_sched_setparam);
+DECL_TEMPLATE(linux, sys_sched_getparam);
+DECL_TEMPLATE(linux, sys_sched_setscheduler);
+DECL_TEMPLATE(linux, sys_sched_getscheduler);
+DECL_TEMPLATE(linux, sys_sched_yield);
+DECL_TEMPLATE(linux, sys_sched_get_priority_max);
+DECL_TEMPLATE(linux, sys_sched_get_priority_min);
+//DECL_TEMPLATE(linux, sys_sched_rr_get_interval); // not yet encount=
ered
+DECL_TEMPLATE(linux, sys_sched_setaffinity);
+DECL_TEMPLATE(linux, sys_sched_getaffinity);
+
#endif // __PRIV_SYSWRAP_LINUX_H
=20
/*--------------------------------------------------------------------*/
Modified: trunk/coregrind/m_syswrap/syswrap-amd64-linux.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_syswrap/syswrap-amd64-linux.c 2005-08-30 01:53:54 U=
TC (rev 4575)
+++ trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-08-30 02:17:23 U=
TC (rev 4576)
@@ -1204,7 +1204,7 @@
GENX_(__NR_access, sys_access), // 21=20
GENXY(__NR_pipe, sys_pipe), // 22=20
GENX_(__NR_select, sys_select), // 23=20
- GENX_(__NR_sched_yield, sys_sched_yield), // 24=20
+ LINX_(__NR_sched_yield, sys_sched_yield), // 24=20
=20
GENX_(__NR_mremap, sys_mremap), // 25=20
GENX_(__NR_msync, sys_msync), // 26=20
@@ -1346,14 +1346,14 @@
=20
// (__NR_getpriority, sys_getpriority), // =
140=20
// (__NR_setpriority, sys_setpriority), // =
141=20
-//zz GENXY(__NR_sched_setparam, sys_sched_setparam), =
// 142=20
- GENXY(__NR_sched_getparam, sys_sched_getparam), // =
143=20
- GENX_(__NR_sched_setscheduler, sys_sched_setscheduler), // =
144=20
+//zz LINXY(__NR_sched_setparam, sys_sched_setparam), =
// 142=20
+ LINXY(__NR_sched_getparam, sys_sched_getparam), // =
143=20
+ LINX_(__NR_sched_setscheduler, sys_sched_setscheduler), // =
144=20
=20
- GENX_(__NR_sched_getscheduler, sys_sched_getscheduler), // =
145=20
- GENX_(__NR_sched_get_priority_max, sys_sched_get_priority_max), // =
146=20
- GENX_(__NR_sched_get_priority_min, sys_sched_get_priority_min), // =
147=20
- // (__NR_sched_rr_get_interval, sys_sched_rr_get_interval), // =
148=20
+ LINX_(__NR_sched_getscheduler, sys_sched_getscheduler), // =
145=20
+ LINX_(__NR_sched_get_priority_max, sys_sched_get_priority_max), // =
146=20
+ LINX_(__NR_sched_get_priority_min, sys_sched_get_priority_min), // =
147=20
+ //LINX?(__NR_sched_rr_get_interval, sys_sched_rr_get_interval), /=
/ 148=20
GENX_(__NR_mlock, sys_mlock), // =
149=20
=20
GENX_(__NR_munlock, sys_munlock), // 150=20
@@ -1419,8 +1419,8 @@
// (__NR_tkill, sys_tkill), // 200=20
GENXY(__NR_time, sys_time), /*was sys_time64*/ // 201=20
LINXY(__NR_futex, sys_futex), // 202=20
- GENX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 203=20
- GENXY(__NR_sched_getaffinity, sys_sched_getaffinity), // 204=20
+ LINX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 203=20
+ LINXY(__NR_sched_getaffinity, sys_sched_getaffinity), // 204=20
=20
// (__NR_set_thread_area, sys_ni_syscall), // 205=20
LINX_(__NR_io_setup, sys_io_setup), // 206=20
Modified: trunk/coregrind/m_syswrap/syswrap-generic.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_syswrap/syswrap-generic.c 2005-08-30 01:53:54 UTC (=
rev 4575)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-08-30 02:17:23 UTC (=
rev 4576)
@@ -1704,13 +1704,6 @@
SET_STATUS_Success(0);
}
=20
-PRE(sys_sched_yield)
-{
- *flags |=3D SfMayBlock;
- PRINT("sched_yield()");
- PRE_REG_READ0(long, "sys_sched_yield");
-}
-
PRE(sys_ni_syscall)
{
PRINT("non-existent syscall! (ni_syscall)");
@@ -1905,22 +1898,6 @@
PRE_REG_READ1(long, "nice", int, inc);
}
=20
-PRE(sys_sched_getscheduler)
-{
- PRINT("sys_sched_getscheduler ( %d )", ARG1);
- PRE_REG_READ1(long, "sched_getscheduler", vki_pid_t, pid);
-}
-
-PRE(sys_sched_setscheduler)
-{
- PRINT("sys_sched_setscheduler ( %d, %d, %p )", ARG1,ARG2,ARG3);
- PRE_REG_READ3(long, "sched_setscheduler",=20
- vki_pid_t, pid, int, policy, struct sched_param *, p);
- if (ARG3 !=3D 0)
- PRE_MEM_READ( "sched_setscheduler(p)",=20
- ARG3, sizeof(struct vki_sched_param));
-}
-
PRE(sys_mlock)
{
*flags |=3D SfMayBlock;
@@ -1949,18 +1926,6 @@
PRE_REG_READ0(long, "munlockall");
}
=20
-PRE(sys_sched_get_priority_max)
-{
- PRINT("sched_get_priority_max ( %d )", ARG1);
- PRE_REG_READ1(long, "sched_get_priority_max", int, policy);
-}
-
-PRE(sys_sched_get_priority_min)
-{
- PRINT("sched_get_priority_min ( %d )", ARG1);
- PRE_REG_READ1(long, "sched_get_priority_min", int, policy);
-}
-
PRE(sys_setpriority)
{
PRINT("sys_setpriority ( %d, %d, %d )", ARG1, ARG2, ARG3);
@@ -4668,31 +4633,6 @@
PRE_MEM_RASCIIZ( "rmdir(pathname)", ARG1 );
}
=20
-PRE(sys_sched_setparam)
-{
- PRINT("sched_setparam ( %d, %p )", ARG1, ARG2 );
- PRE_REG_READ2(long, "sched_setparam",=20
- vki_pid_t, pid, struct sched_param *, p);
- PRE_MEM_READ( "sched_setparam(p)", ARG2, sizeof(struct vki_sched_para=
m) );
-}
-POST(sys_sched_setparam)
-{
- POST_MEM_WRITE( ARG2, sizeof(struct vki_sched_param) );
-}
-
-PRE(sys_sched_getparam)
-{
- PRINT("sched_getparam ( %d, %p )", ARG1, ARG2 );
- PRE_REG_READ2(long, "sched_getparam",=20
- vki_pid_t, pid, struct sched_param *, p);
- PRE_MEM_WRITE( "sched_getparam(p)", ARG2, sizeof(struct vki_sched_par=
am) );
-}
-
-POST(sys_sched_getparam)
-{
- POST_MEM_WRITE( ARG2, sizeof(struct vki_sched_param) );
-}
-
PRE(sys_select)
{
*flags |=3D SfMayBlock;
@@ -4988,26 +4928,6 @@
PRE_MEM_READ( "utimes(tvp)", ARG2, sizeof(struct vki_timeval) );
}
=20
-PRE(sys_sched_setaffinity)
-{
- PRINT("sched_setaffinity ( %d, %d, %p )", ARG1, ARG2, ARG3);
- PRE_REG_READ3(long, "sched_setaffinity",=20
- vki_pid_t, pid, unsigned int, len, unsigned long *, mas=
k);
- PRE_MEM_READ( "sched_setaffinity(mask)", ARG3, ARG2);
-}
-
-PRE(sys_sched_getaffinity)
-{
- PRINT("sched_getaffinity ( %d, %d, %p )", ARG1, ARG2, ARG3);
- PRE_REG_READ3(long, "sched_getaffinity",=20
- vki_pid_t, pid, unsigned int, len, unsigned long *, mas=
k);
- PRE_MEM_WRITE( "sched_getaffinity(mask)", ARG3, ARG2);
-}
-POST(sys_sched_getaffinity)
-{
- POST_MEM_WRITE(ARG3, ARG2);
-}
-
PRE(sys_acct)
{
PRINT("sys_acct ( %p )", ARG1);
Modified: trunk/coregrind/m_syswrap/syswrap-linux.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_syswrap/syswrap-linux.c 2005-08-30 01:53:54 UTC (re=
v 4575)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2005-08-30 02:17:23 UTC (re=
v 4576)
@@ -1400,6 +1400,85 @@
PRE_MEM_RASCIIZ( "fremovexattr(name)", ARG2 );
}
=20
+PRE(sys_sched_setparam)
+{
+ PRINT("sched_setparam ( %d, %p )", ARG1, ARG2 );
+ PRE_REG_READ2(long, "sched_setparam",=20
+ vki_pid_t, pid, struct sched_param *, p);
+ PRE_MEM_READ( "sched_setparam(p)", ARG2, sizeof(struct vki_sched_para=
m) );
+}
+POST(sys_sched_setparam)
+{
+ POST_MEM_WRITE( ARG2, sizeof(struct vki_sched_param) );
+}
+
+PRE(sys_sched_getparam)
+{
+ PRINT("sched_getparam ( %d, %p )", ARG1, ARG2 );
+ PRE_REG_READ2(long, "sched_getparam",=20
+ vki_pid_t, pid, struct sched_param *, p);
+ PRE_MEM_WRITE( "sched_getparam(p)", ARG2, sizeof(struct vki_sched_par=
am) );
+}
+POST(sys_sched_getparam)
+{
+ POST_MEM_WRITE( ARG2, sizeof(struct vki_sched_param) );
+}
+
+PRE(sys_sched_getscheduler)
+{
+ PRINT("sys_sched_getscheduler ( %d )", ARG1);
+ PRE_REG_READ1(long, "sched_getscheduler", vki_pid_t, pid);
+}
+
+PRE(sys_sched_setscheduler)
+{
+ PRINT("sys_sched_setscheduler ( %d, %d, %p )", ARG1,ARG2,ARG3);
+ PRE_REG_READ3(long, "sched_setscheduler",=20
+ vki_pid_t, pid, int, policy, struct sched_param *, p);
+ if (ARG3 !=3D 0)
+ PRE_MEM_READ( "sched_setscheduler(p)",=20
+ ARG3, sizeof(struct vki_sched_param));
+}
+
+PRE(sys_sched_yield)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sched_yield()");
+ PRE_REG_READ0(long, "sys_sched_yield");
+}
+
+PRE(sys_sched_get_priority_max)
+{
+ PRINT("sched_get_priority_max ( %d )", ARG1);
+ PRE_REG_READ1(long, "sched_get_priority_max", int, policy);
+}
+
+PRE(sys_sched_get_priority_min)
+{
+ PRINT("sched_get_priority_min ( %d )", ARG1);
+ PRE_REG_READ1(long, "sched_get_priority_min", int, policy);
+}
+
+PRE(sys_sched_setaffinity)
+{
+ PRINT("sched_setaffinity ( %d, %d, %p )", ARG1, ARG2, ARG3);
+ PRE_REG_READ3(long, "sched_setaffinity",=20
+ vki_pid_t, pid, unsigned int, len, unsigned long *, mas=
k);
+ PRE_MEM_READ( "sched_setaffinity(mask)", ARG3, ARG2);
+}
+
+PRE(sys_sched_getaffinity)
+{
+ PRINT("sched_getaffinity ( %d, %d, %p )", ARG1, ARG2, ARG3);
+ PRE_REG_READ3(long, "sched_getaffinity",=20
+ vki_pid_t, pid, unsigned int, len, unsigned long *, mas=
k);
+ PRE_MEM_WRITE( "sched_getaffinity(mask)", ARG3, ARG2);
+}
+POST(sys_sched_getaffinity)
+{
+ POST_MEM_WRITE(ARG3, ARG2);
+}
+
#undef PRE
#undef POST
=20
Modified: trunk/coregrind/m_syswrap/syswrap-ppc32-linux.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_syswrap/syswrap-ppc32-linux.c 2005-08-30 01:53:54 U=
TC (rev 4575)
+++ trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c 2005-08-30 02:17:23 U=
TC (rev 4576)
@@ -2144,16 +2144,16 @@
//.. GENX_(__NR_munlock, sys_munlock), // 151
//.. GENX_(__NR_mlockall, sys_mlockall), // 152
//.. GENX_(__NR_munlockall, sys_munlockall), // 153
-//.. GENXY(__NR_sched_setparam, sys_sched_setparam), // 154
+//.. LINXY(__NR_sched_setparam, sys_sched_setparam), // 154
//..=20
- GENXY(__NR_sched_getparam, sys_sched_getparam), // 155
-//.. GENX_(__NR_sched_setscheduler, sys_sched_setscheduler), /=
/ 156
- GENX_(__NR_sched_getscheduler, sys_sched_getscheduler), // 157
-//.. GENX_(__NR_sched_yield, sys_sched_yield), /=
/ 158
- GENX_(__NR_sched_get_priority_max, sys_sched_get_priority_max),// 159
+ LINXY(__NR_sched_getparam, sys_sched_getparam), // 155
+//.. LINX_(__NR_sched_setscheduler, sys_sched_setscheduler), /=
/ 156
+ LINX_(__NR_sched_getscheduler, sys_sched_getscheduler), // 157
+//.. LINX_(__NR_sched_yield, sys_sched_yield), /=
/ 158
+ LINX_(__NR_sched_get_priority_max, sys_sched_get_priority_max),// 159
=20
- GENX_(__NR_sched_get_priority_min, sys_sched_get_priority_min),// 160
-//.. // (__NR_sched_rr_get_interval, sys_sched_rr_get_interval), /=
/ 161 */*
+ LINX_(__NR_sched_get_priority_min, sys_sched_get_priority_min),// 160
+//.. //LINX?(__NR_sched_rr_get_interval, sys_sched_rr_get_interval),=
// 161 */*
GENXY(__NR_nanosleep, sys_nanosleep), // 162
GENX_(__NR_mremap, sys_mremap), // 163
LINX_(__NR_setresuid, sys_setresuid16), // 164
@@ -2227,8 +2227,8 @@
//.. LINX_(__NR_fremovexattr, sys_fremovexattr), // 220
=20
LINXY(__NR_futex, sys_futex), // 221
-//.. GENX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 222
-//.. GENXY(__NR_sched_getaffinity, sys_sched_getaffinity), // 223
+//.. LINX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 222
+//.. LINXY(__NR_sched_getaffinity, sys_sched_getaffinity), // 223
/* 224 currently unused */
=20
// __NR_tuxcall // 225
Modified: trunk/coregrind/m_syswrap/syswrap-x86-linux.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_syswrap/syswrap-x86-linux.c 2005-08-30 01:53:54 UTC=
(rev 4575)
+++ trunk/coregrind/m_syswrap/syswrap-x86-linux.c 2005-08-30 02:17:23 UTC=
(rev 4576)
@@ -2126,16 +2126,16 @@
GENX_(__NR_munlock, sys_munlock), // 151
GENX_(__NR_mlockall, sys_mlockall), // 152
GENX_(__NR_munlockall, sys_munlockall), // 153
- GENXY(__NR_sched_setparam, sys_sched_setparam), // 154
+ LINXY(__NR_sched_setparam, sys_sched_setparam), // 154
=20
- GENXY(__NR_sched_getparam, sys_sched_getparam), // 155
- GENX_(__NR_sched_setscheduler, sys_sched_setscheduler), // 156
- GENX_(__NR_sched_getscheduler, sys_sched_getscheduler), // 157
- GENX_(__NR_sched_yield, sys_sched_yield), // 158
- GENX_(__NR_sched_get_priority_max, sys_sched_get_priority_max),// 159
+ LINXY(__NR_sched_getparam, sys_sched_getparam), // 155
+ LINX_(__NR_sched_setscheduler, sys_sched_setscheduler), // 156
+ LINX_(__NR_sched_getscheduler, sys_sched_getscheduler), // 157
+ LINX_(__NR_sched_yield, sys_sched_yield), // 158
+ LINX_(__NR_sched_get_priority_max, sys_sched_get_priority_max),// 159
=20
- GENX_(__NR_sched_get_priority_min, sys_sched_get_priority_min),// 160
-//zz // (__NR_sched_rr_get_interval, sys_sched_rr_get_interval), /=
/ 161 */*
+ LINX_(__NR_sched_get_priority_min, sys_sched_get_priority_min),// 160
+//zz //LINX?(__NR_sched_rr_get_interval, sys_sched_rr_get_interval),=
// 161 */*
GENXY(__NR_nanosleep, sys_nanosleep), // 162
GENX_(__NR_mremap, sys_mremap), // 163
LINX_(__NR_setresuid, sys_setresuid16), // 164
@@ -2232,8 +2232,8 @@
LINXY(__NR_sendfile64, sys_sendfile64), // 239
=20
LINXY(__NR_futex, sys_futex), // 240
- GENX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 241
- GENXY(__NR_sched_getaffinity, sys_sched_getaffinity), // 242
+ LINX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 241
+ LINXY(__NR_sched_getaffinity, sys_sched_getaffinity), // 242
PLAX_(__NR_set_thread_area, sys_set_thread_area), // 243
PLAX_(__NR_get_thread_area, sys_get_thread_area), // 244
=20
|
|
From: Tom H. <th...@cy...> - 2005-08-30 02:16:38
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-08-30 03:05:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 164 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-08-30 02:12:50
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-08-30 03:00:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 164 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: <sv...@va...> - 2005-08-30 01:53:59
|
Author: njn
Date: 2005-08-30 02:53:54 +0100 (Tue, 30 Aug 2005)
New Revision: 4575
Log:
Move *xattr from "generic" to "linux". Darwin has them, but with an extr=
a
parameter.
Modified:
trunk/coregrind/m_syswrap/priv_syswrap-generic.h
trunk/coregrind/m_syswrap/priv_syswrap-linux.h
trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c
trunk/coregrind/m_syswrap/syswrap-x86-linux.c
Modified: trunk/coregrind/m_syswrap/priv_syswrap-generic.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/coregrind/m_syswrap/priv_syswrap-generic.h 2005-08-30 01:06:13 =
UTC (rev 4574)
+++ trunk/coregrind/m_syswrap/priv_syswrap-generic.h 2005-08-30 01:53:54 =
UTC (rev 4575)
@@ -209,18 +209,6 @@
DECL_TEMPLATE(generic, sys_mincore); // * L?
DECL_TEMPLATE(generic, sys_getdents64); // * (SVr4,SVID?)
DECL_TEMPLATE(generic, sys_fcntl64); // * P?
-DECL_TEMPLATE(generic, sys_setxattr); // * L?
-DECL_TEMPLATE(generic, sys_lsetxattr); // * L?
-DECL_TEMPLATE(generic, sys_fsetxattr); // * L?
-DECL_TEMPLATE(generic, sys_getxattr); // * L?
-DECL_TEMPLATE(generic, sys_lgetxattr); // * L?
-DECL_TEMPLATE(generic, sys_fgetxattr); // * L?
-DECL_TEMPLATE(generic, sys_listxattr); // * L?
-DECL_TEMPLATE(generic, sys_llistxattr); // * L?
-DECL_TEMPLATE(generic, sys_flistxattr); // * L?
-DECL_TEMPLATE(generic, sys_removexattr); // * L?
-DECL_TEMPLATE(generic, sys_lremovexattr); // * L?
-DECL_TEMPLATE(generic, sys_fremovexattr); // * L?
DECL_TEMPLATE(generic, sys_sched_setaffinity); // * L?
DECL_TEMPLATE(generic, sys_sched_getaffinity); // * L?
DECL_TEMPLATE(generic, sys_lookup_dcookie); // (*/32/64) L
Modified: trunk/coregrind/m_syswrap/priv_syswrap-linux.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/coregrind/m_syswrap/priv_syswrap-linux.h 2005-08-30 01:06:13 UT=
C (rev 4574)
+++ trunk/coregrind/m_syswrap/priv_syswrap-linux.h 2005-08-30 01:53:54 UT=
C (rev 4575)
@@ -136,6 +136,19 @@
DECL_TEMPLATE(linux, sys_fchown16);
//DECL_TEMPLATE(linux, sys_lchown16); // not yet encountered
=20
+// Are these POSIX? In Darwin they have an extra parameter 'position'.
+DECL_TEMPLATE(linux, sys_setxattr);
+DECL_TEMPLATE(linux, sys_lsetxattr);
+DECL_TEMPLATE(linux, sys_fsetxattr);
+DECL_TEMPLATE(linux, sys_getxattr);
+DECL_TEMPLATE(linux, sys_lgetxattr);
+DECL_TEMPLATE(linux, sys_fgetxattr);
+DECL_TEMPLATE(linux, sys_listxattr);
+DECL_TEMPLATE(linux, sys_llistxattr);
+DECL_TEMPLATE(linux, sys_flistxattr);
+DECL_TEMPLATE(linux, sys_removexattr);
+DECL_TEMPLATE(linux, sys_lremovexattr);
+DECL_TEMPLATE(linux, sys_fremovexattr);
#endif // __PRIV_SYSWRAP_LINUX_H
=20
/*--------------------------------------------------------------------*/
Modified: trunk/coregrind/m_syswrap/syswrap-amd64-linux.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_syswrap/syswrap-amd64-linux.c 2005-08-30 01:06:13 U=
TC (rev 4574)
+++ trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-08-30 01:53:54 U=
TC (rev 4575)
@@ -1401,20 +1401,20 @@
// (__NR_security, sys_ni_syscall), // 185=20
LINX_(__NR_gettid, sys_gettid), // 186=20
// (__NR_readahead, sys_readahead), // 187=20
- // (__NR_setxattr, sys_setxattr), // 188=20
- // (__NR_lsetxattr, sys_lsetxattr), // 189=20
+ //LINX_(__NR_setxattr, sys_setxattr), // 188=20
+ //LINX_(__NR_lsetxattr, sys_lsetxattr), // 189=20
=20
- // (__NR_fsetxattr, sys_fsetxattr), // 190=20
- GENXY(__NR_getxattr, sys_getxattr), // 191=20
- // (__NR_lgetxattr, sys_lgetxattr), // 192=20
- // (__NR_fgetxattr, sys_fgetxattr), // 193=20
- // (__NR_listxattr, sys_listxattr), // 194=20
+ //LINX_(__NR_fsetxattr, sys_fsetxattr), // 190=20
+ LINXY(__NR_getxattr, sys_getxattr), // 191=20
+ //LINXY(__NR_lgetxattr, sys_lgetxattr), // 192=20
+ //LINXY(__NR_fgetxattr, sys_fgetxattr), // 193=20
+ //LINXY(__NR_listxattr, sys_listxattr), // 194=20
=20
- // (__NR_llistxattr, sys_llistxattr), // 195=20
- // (__NR_flistxattr, sys_flistxattr), // 196=20
- // (__NR_removexattr, sys_removexattr), // 197=20
- // (__NR_lremovexattr, sys_lremovexattr), // 198=20
- // (__NR_fremovexattr, sys_fremovexattr), // 199=20
+ //LINXY(__NR_llistxattr, sys_llistxattr), // 195=20
+ //LINXY(__NR_flistxattr, sys_flistxattr), // 196=20
+ //LINX_(__NR_removexattr, sys_removexattr), // 197=20
+ //LINX_(__NR_lremovexattr, sys_lremovexattr), // 198=20
+ //LINX_(__NR_fremovexattr, sys_fremovexattr), // 199=20
=20
// (__NR_tkill, sys_tkill), // 200=20
GENXY(__NR_time, sys_time), /*was sys_time64*/ // 201=20
Modified: trunk/coregrind/m_syswrap/syswrap-generic.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_syswrap/syswrap-generic.c 2005-08-30 01:06:13 UTC (=
rev 4574)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-08-30 01:53:54 UTC (=
rev 4575)
@@ -1724,165 +1724,6 @@
PRE_REG_READ1(long, "iopl", unsigned long, level);
}
=20
-PRE(sys_setxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_setxattr ( %p, %p, %p, %llu, %d )",
- ARG1, ARG2, ARG3, (ULong)ARG4, ARG5);
- PRE_REG_READ5(long, "setxattr",
- char *, path, char *, name,
- void *, value, vki_size_t, size, int, flags);
- PRE_MEM_RASCIIZ( "setxattr(path)", ARG1 );
- PRE_MEM_RASCIIZ( "setxattr(name)", ARG2 );
- PRE_MEM_READ( "setxattr(value)", ARG3, ARG4 );
-}
-
-PRE(sys_lsetxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_lsetxattr ( %p, %p, %p, %llu, %d )",
- ARG1, ARG2, ARG3, (ULong)ARG4, ARG5);
- PRE_REG_READ5(long, "lsetxattr",
- char *, path, char *, name,
- void *, value, vki_size_t, size, int, flags);
- PRE_MEM_RASCIIZ( "lsetxattr(path)", ARG1 );
- PRE_MEM_RASCIIZ( "lsetxattr(name)", ARG2 );
- PRE_MEM_READ( "lsetxattr(value)", ARG3, ARG4 );
-}
-
-PRE(sys_fsetxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_fsetxattr ( %d, %p, %p, %llu, %d )",
- ARG1, ARG2, ARG3, (ULong)ARG4, ARG5);
- PRE_REG_READ5(long, "fsetxattr",
- int, fd, char *, name, void *, value,
- vki_size_t, size, int, flags);
- PRE_MEM_RASCIIZ( "fsetxattr(name)", ARG2 );
- PRE_MEM_READ( "fsetxattr(value)", ARG3, ARG4 );
-}
-
-PRE(sys_getxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_getxattr ( %p, %p, %p, %llu )", ARG1,ARG2,ARG3, (ULong)ARG=
4);
- PRE_REG_READ4(ssize_t, "getxattr",
- char *, path, char *, name, void *, value, vki_size_t, =
size);
- PRE_MEM_RASCIIZ( "getxattr(path)", ARG1 );
- PRE_MEM_RASCIIZ( "getxattr(name)", ARG2 );
- PRE_MEM_WRITE( "getxattr(value)", ARG3, ARG4 );
-}
-POST(sys_getxattr)
-{
- vg_assert(SUCCESS);
- if (RES > 0 && ARG3 !=3D (Addr)NULL) {
- POST_MEM_WRITE( ARG3, RES );
- }
-}
-
-PRE(sys_lgetxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_lgetxattr ( %p, %p, %p, %llu )", ARG1,ARG2,ARG3, (ULong)AR=
G4);
- PRE_REG_READ4(ssize_t, "lgetxattr",
- char *, path, char *, name, void *, value, vki_size_t, =
size);
- PRE_MEM_RASCIIZ( "lgetxattr(path)", ARG1 );
- PRE_MEM_RASCIIZ( "lgetxattr(name)", ARG2 );
- PRE_MEM_WRITE( "lgetxattr(value)", ARG3, ARG4 );
-}
-POST(sys_lgetxattr)
-{
- vg_assert(SUCCESS);
- if (RES > 0 && ARG3 !=3D (Addr)NULL) {
- POST_MEM_WRITE( ARG3, RES );
- }
-}
-
-PRE(sys_fgetxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_fgetxattr ( %d, %p, %p, %llu )", ARG1, ARG2, ARG3, (ULong)=
ARG4);
- PRE_REG_READ4(ssize_t, "fgetxattr",
- int, fd, char *, name, void *, value, vki_size_t, size)=
;
- PRE_MEM_RASCIIZ( "fgetxattr(name)", ARG2 );
- PRE_MEM_WRITE( "fgetxattr(value)", ARG3, ARG4 );
-}
-POST(sys_fgetxattr)
-{
- if (RES > 0 && ARG3 !=3D (Addr)NULL)
- POST_MEM_WRITE( ARG3, RES );
-}
-
-PRE(sys_listxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_listxattr ( %p, %p, %llu )", ARG1, ARG2, (ULong)ARG3);
- PRE_REG_READ3(ssize_t, "listxattr",
- char *, path, char *, list, vki_size_t, size);
- PRE_MEM_RASCIIZ( "listxattr(path)", ARG1 );
- PRE_MEM_WRITE( "listxattr(list)", ARG2, ARG3 );
-}
-POST(sys_listxattr)
-{
- if (RES > 0 && ARG2 !=3D (Addr)NULL)
- POST_MEM_WRITE( ARG2, RES );
-}
-
-PRE(sys_llistxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_llistxattr ( %p, %p, %llu )", ARG1, ARG2, (ULong)ARG3);
- PRE_REG_READ3(ssize_t, "llistxattr",
- char *, path, char *, list, vki_size_t, size);
- PRE_MEM_RASCIIZ( "llistxattr(path)", ARG1 );
- PRE_MEM_WRITE( "llistxattr(list)", ARG2, ARG3 );
-}
-POST(sys_llistxattr)
-{
- if (RES > 0 && ARG2 !=3D (Addr)NULL)
- POST_MEM_WRITE( ARG2, RES );
-}
-
-PRE(sys_flistxattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_flistxattr ( %d, %p, %llu )", ARG1, ARG2, (ULong)ARG3);
- PRE_REG_READ3(ssize_t, "flistxattr",
- int, fd, char *, list, vki_size_t, size);
- PRE_MEM_WRITE( "flistxattr(list)", ARG2, ARG3 );
-}
-POST(sys_flistxattr)
-{
- if (RES > 0 && ARG2 !=3D (Addr)NULL)
- POST_MEM_WRITE( ARG2, RES );
-}
-
-PRE(sys_removexattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_removexattr ( %p, %p )", ARG1, ARG2);
- PRE_REG_READ2(long, "removexattr", char *, path, char *, name);
- PRE_MEM_RASCIIZ( "removexattr(path)", ARG1 );
- PRE_MEM_RASCIIZ( "removexattr(name)", ARG2 );
-}
-
-PRE(sys_lremovexattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_lremovexattr ( %p, %p )", ARG1, ARG2);
- PRE_REG_READ2(long, "lremovexattr", char *, path, char *, name);
- PRE_MEM_RASCIIZ( "lremovexattr(path)", ARG1 );
- PRE_MEM_RASCIIZ( "lremovexattr(name)", ARG2 );
-}
-
-PRE(sys_fremovexattr)
-{
- *flags |=3D SfMayBlock;
- PRINT("sys_fremovexattr ( %d, %p )", ARG1, ARG2);
- PRE_REG_READ2(long, "fremovexattr", int, fd, char *, name);
- PRE_MEM_RASCIIZ( "fremovexattr(name)", ARG2 );
-}
-
PRE(sys_quotactl)
{
PRINT("sys_quotactl (0x%x, %p, 0x%x, 0x%x )", ARG1,ARG2,ARG3, ARG4);
Modified: trunk/coregrind/m_syswrap/syswrap-linux.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_syswrap/syswrap-linux.c 2005-08-30 01:06:13 UTC (re=
v 4574)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2005-08-30 01:53:54 UTC (re=
v 4575)
@@ -1241,6 +1241,165 @@
unsigned int, fd, vki_old_uid_t, owner, vki_old_gid_t, =
group);
}
=20
+PRE(sys_setxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_setxattr ( %p, %p, %p, %llu, %d )",
+ ARG1, ARG2, ARG3, (ULong)ARG4, ARG5);
+ PRE_REG_READ5(long, "setxattr",
+ char *, path, char *, name,
+ void *, value, vki_size_t, size, int, flags);
+ PRE_MEM_RASCIIZ( "setxattr(path)", ARG1 );
+ PRE_MEM_RASCIIZ( "setxattr(name)", ARG2 );
+ PRE_MEM_READ( "setxattr(value)", ARG3, ARG4 );
+}
+
+PRE(sys_lsetxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_lsetxattr ( %p, %p, %p, %llu, %d )",
+ ARG1, ARG2, ARG3, (ULong)ARG4, ARG5);
+ PRE_REG_READ5(long, "lsetxattr",
+ char *, path, char *, name,
+ void *, value, vki_size_t, size, int, flags);
+ PRE_MEM_RASCIIZ( "lsetxattr(path)", ARG1 );
+ PRE_MEM_RASCIIZ( "lsetxattr(name)", ARG2 );
+ PRE_MEM_READ( "lsetxattr(value)", ARG3, ARG4 );
+}
+
+PRE(sys_fsetxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_fsetxattr ( %d, %p, %p, %llu, %d )",
+ ARG1, ARG2, ARG3, (ULong)ARG4, ARG5);
+ PRE_REG_READ5(long, "fsetxattr",
+ int, fd, char *, name, void *, value,
+ vki_size_t, size, int, flags);
+ PRE_MEM_RASCIIZ( "fsetxattr(name)", ARG2 );
+ PRE_MEM_READ( "fsetxattr(value)", ARG3, ARG4 );
+}
+
+PRE(sys_getxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_getxattr ( %p, %p, %p, %llu )", ARG1,ARG2,ARG3, (ULong)ARG=
4);
+ PRE_REG_READ4(ssize_t, "getxattr",
+ char *, path, char *, name, void *, value, vki_size_t, =
size);
+ PRE_MEM_RASCIIZ( "getxattr(path)", ARG1 );
+ PRE_MEM_RASCIIZ( "getxattr(name)", ARG2 );
+ PRE_MEM_WRITE( "getxattr(value)", ARG3, ARG4 );
+}
+POST(sys_getxattr)
+{
+ vg_assert(SUCCESS);
+ if (RES > 0 && ARG3 !=3D (Addr)NULL) {
+ POST_MEM_WRITE( ARG3, RES );
+ }
+}
+
+PRE(sys_lgetxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_lgetxattr ( %p, %p, %p, %llu )", ARG1,ARG2,ARG3, (ULong)AR=
G4);
+ PRE_REG_READ4(ssize_t, "lgetxattr",
+ char *, path, char *, name, void *, value, vki_size_t, =
size);
+ PRE_MEM_RASCIIZ( "lgetxattr(path)", ARG1 );
+ PRE_MEM_RASCIIZ( "lgetxattr(name)", ARG2 );
+ PRE_MEM_WRITE( "lgetxattr(value)", ARG3, ARG4 );
+}
+POST(sys_lgetxattr)
+{
+ vg_assert(SUCCESS);
+ if (RES > 0 && ARG3 !=3D (Addr)NULL) {
+ POST_MEM_WRITE( ARG3, RES );
+ }
+}
+
+PRE(sys_fgetxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_fgetxattr ( %d, %p, %p, %llu )", ARG1, ARG2, ARG3, (ULong)=
ARG4);
+ PRE_REG_READ4(ssize_t, "fgetxattr",
+ int, fd, char *, name, void *, value, vki_size_t, size)=
;
+ PRE_MEM_RASCIIZ( "fgetxattr(name)", ARG2 );
+ PRE_MEM_WRITE( "fgetxattr(value)", ARG3, ARG4 );
+}
+POST(sys_fgetxattr)
+{
+ if (RES > 0 && ARG3 !=3D (Addr)NULL)
+ POST_MEM_WRITE( ARG3, RES );
+}
+
+PRE(sys_listxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_listxattr ( %p, %p, %llu )", ARG1, ARG2, (ULong)ARG3);
+ PRE_REG_READ3(ssize_t, "listxattr",
+ char *, path, char *, list, vki_size_t, size);
+ PRE_MEM_RASCIIZ( "listxattr(path)", ARG1 );
+ PRE_MEM_WRITE( "listxattr(list)", ARG2, ARG3 );
+}
+POST(sys_listxattr)
+{
+ if (RES > 0 && ARG2 !=3D (Addr)NULL)
+ POST_MEM_WRITE( ARG2, RES );
+}
+
+PRE(sys_llistxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_llistxattr ( %p, %p, %llu )", ARG1, ARG2, (ULong)ARG3);
+ PRE_REG_READ3(ssize_t, "llistxattr",
+ char *, path, char *, list, vki_size_t, size);
+ PRE_MEM_RASCIIZ( "llistxattr(path)", ARG1 );
+ PRE_MEM_WRITE( "llistxattr(list)", ARG2, ARG3 );
+}
+POST(sys_llistxattr)
+{
+ if (RES > 0 && ARG2 !=3D (Addr)NULL)
+ POST_MEM_WRITE( ARG2, RES );
+}
+
+PRE(sys_flistxattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_flistxattr ( %d, %p, %llu )", ARG1, ARG2, (ULong)ARG3);
+ PRE_REG_READ3(ssize_t, "flistxattr",
+ int, fd, char *, list, vki_size_t, size);
+ PRE_MEM_WRITE( "flistxattr(list)", ARG2, ARG3 );
+}
+POST(sys_flistxattr)
+{
+ if (RES > 0 && ARG2 !=3D (Addr)NULL)
+ POST_MEM_WRITE( ARG2, RES );
+}
+
+PRE(sys_removexattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_removexattr ( %p, %p )", ARG1, ARG2);
+ PRE_REG_READ2(long, "removexattr", char *, path, char *, name);
+ PRE_MEM_RASCIIZ( "removexattr(path)", ARG1 );
+ PRE_MEM_RASCIIZ( "removexattr(name)", ARG2 );
+}
+
+PRE(sys_lremovexattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_lremovexattr ( %p, %p )", ARG1, ARG2);
+ PRE_REG_READ2(long, "lremovexattr", char *, path, char *, name);
+ PRE_MEM_RASCIIZ( "lremovexattr(path)", ARG1 );
+ PRE_MEM_RASCIIZ( "lremovexattr(name)", ARG2 );
+}
+
+PRE(sys_fremovexattr)
+{
+ *flags |=3D SfMayBlock;
+ PRINT("sys_fremovexattr ( %d, %p )", ARG1, ARG2);
+ PRE_REG_READ2(long, "fremovexattr", int, fd, char *, name);
+ PRE_MEM_RASCIIZ( "fremovexattr(name)", ARG2 );
+}
+
#undef PRE
#undef POST
=20
Modified: trunk/coregrind/m_syswrap/syswrap-ppc32-linux.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_syswrap/syswrap-ppc32-linux.c 2005-08-30 01:06:13 U=
TC (rev 4574)
+++ trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c 2005-08-30 01:53:54 U=
TC (rev 4575)
@@ -2213,18 +2213,18 @@
//.. GENXY(__NR_mincore, sys_mincore), // 206
LINX_(__NR_gettid, sys_gettid), // 207
//.. LINX_(__NR_tkill, sys_tkill), // 208 */L=
inux
-//.. GENX_(__NR_setxattr, sys_setxattr), // 209
-//.. GENX_(__NR_lsetxattr, sys_lsetxattr), // 210
-//.. GENX_(__NR_fsetxattr, sys_fsetxattr), // 211
+//.. LINX_(__NR_setxattr, sys_setxattr), // 209
+//.. LINX_(__NR_lsetxattr, sys_lsetxattr), // 210
+//.. LINX_(__NR_fsetxattr, sys_fsetxattr), // 211
GENXY(__NR_getxattr, sys_getxattr), // 212
-//.. GENXY(__NR_lgetxattr, sys_lgetxattr), // 213
-//.. GENXY(__NR_fgetxattr, sys_fgetxattr), // 214
-//.. GENXY(__NR_listxattr, sys_listxattr), // 215
-//.. GENXY(__NR_llistxattr, sys_llistxattr), // 216
-//.. GENXY(__NR_flistxattr, sys_flistxattr), // 217
-//.. GENX_(__NR_removexattr, sys_removexattr), // 218
-//.. GENX_(__NR_lremovexattr, sys_lremovexattr), // 219
-//.. GENX_(__NR_fremovexattr, sys_fremovexattr), // 220
+//.. LINXY(__NR_lgetxattr, sys_lgetxattr), // 213
+//.. LINXY(__NR_fgetxattr, sys_fgetxattr), // 214
+//.. LINXY(__NR_listxattr, sys_listxattr), // 215
+//.. LINXY(__NR_llistxattr, sys_llistxattr), // 216
+//.. LINXY(__NR_flistxattr, sys_flistxattr), // 217
+//.. LINX_(__NR_removexattr, sys_removexattr), // 218
+//.. LINX_(__NR_lremovexattr, sys_lremovexattr), // 219
+//.. LINX_(__NR_fremovexattr, sys_fremovexattr), // 220
=20
LINXY(__NR_futex, sys_futex), // 221
//.. GENX_(__NR_sched_setaffinity, sys_sched_setaffinity), // 222
Modified: trunk/coregrind/m_syswrap/syswrap-x86-linux.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_syswrap/syswrap-x86-linux.c 2005-08-30 01:06:13 UTC=
(rev 4574)
+++ trunk/coregrind/m_syswrap/syswrap-x86-linux.c 2005-08-30 01:53:54 UTC=
(rev 4575)
@@ -2214,20 +2214,20 @@
LINX_(__NR_gettid, sys_gettid), // 224
=20
//zz // (__NR_readahead, sys_readahead), // 225 */(Lin=
ux?)
- GENX_(__NR_setxattr, sys_setxattr), // 226
- GENX_(__NR_lsetxattr, sys_lsetxattr), // 227
- GENX_(__NR_fsetxattr, sys_fsetxattr), // 228
- GENXY(__NR_getxattr, sys_getxattr), // 229
+ LINX_(__NR_setxattr, sys_setxattr), // 226
+ LINX_(__NR_lsetxattr, sys_lsetxattr), // 227
+ LINX_(__NR_fsetxattr, sys_fsetxattr), // 228
+ LINXY(__NR_getxattr, sys_getxattr), // 229
=20
- GENXY(__NR_lgetxattr, sys_lgetxattr), // 230
- GENXY(__NR_fgetxattr, sys_fgetxattr), // 231
- GENXY(__NR_listxattr, sys_listxattr), // 232
- GENXY(__NR_llistxattr, sys_llistxattr), // 233
- GENXY(__NR_flistxattr, sys_flistxattr), // 234
+ LINXY(__NR_lgetxattr, sys_lgetxattr), // 230
+ LINXY(__NR_fgetxattr, sys_fgetxattr), // 231
+ LINXY(__NR_listxattr, sys_listxattr), // 232
+ LINXY(__NR_llistxattr, sys_llistxattr), // 233
+ LINXY(__NR_flistxattr, sys_flistxattr), // 234
=20
- GENX_(__NR_removexattr, sys_removexattr), // 235
- GENX_(__NR_lremovexattr, sys_lremovexattr), // 236
- GENX_(__NR_fremovexattr, sys_fremovexattr), // 237
+ LINX_(__NR_removexattr, sys_removexattr), // 235
+ LINX_(__NR_lremovexattr, sys_lremovexattr), // 236
+ LINX_(__NR_fremovexattr, sys_fremovexattr), // 237
//zz LINX_(__NR_tkill, sys_tkill), // 238 */Linu=
x
LINXY(__NR_sendfile64, sys_sendfile64), // 239
=20
|
|
From: <sv...@va...> - 2005-08-30 01:06:15
|
Author: sewardj Date: 2005-08-30 02:06:13 +0100 (Tue, 30 Aug 2005) New Revision: 4574 Log: Final changes for 3.0.1. Modified: branches/VALGRIND_3_0_BRANCH/NEWS Modified: branches/VALGRIND_3_0_BRANCH/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-30 01:05:54 UTC (rev 4573) +++ branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-30 01:06:13 UTC (rev 4574) @@ -3,7 +3,7 @@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.1 fixes a bunch of bugs reported in 3.0.0. There is no new functionality. Some of the fixed bugs are critical, so if you -use/distribute 3.0.0, and upgrade to 3.0.1 is recommended. The fixed +use/distribute 3.0.0, an upgrade to 3.0.1 is recommended. The fixed bugs are: =20 (note: "n-i-bz" means "not in bugzilla" -- this bug does not have @@ -51,9 +51,9 @@ 111555 VEX/Makefile: CC is set to gcc n-i-bz Fix XML bugs in FAQ =20 =20 -(3.0.1RC1: 29 August 05,=20 - vex/branches/VEX_3_0_BRANCH r1367,=20 - valgrind/branches/VALGRIND_3_0_BRANCH r4570). +(3.0.1: 29 August 05,=20 + vex/branches/VEX_3_0_BRANCH r1367,=20 + valgrind/branches/VALGRIND_3_0_BRANCH r4574). =20 =20 =20 |
|
From: <sv...@va...> - 2005-08-30 01:05:59
|
Author: sewardj Date: 2005-08-30 02:05:54 +0100 (Tue, 30 Aug 2005) New Revision: 4573 Log: --> 3.0.1 Modified: branches/VALGRIND_3_0_BRANCH/configure.in Modified: branches/VALGRIND_3_0_BRANCH/configure.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/VALGRIND_3_0_BRANCH/configure.in 2005-08-29 22:24:20 UTC (re= v 4572) +++ branches/VALGRIND_3_0_BRANCH/configure.in 2005-08-30 01:05:54 UTC (re= v 4573) @@ -1,5 +1,5 @@ # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.0.1RC1, val...@li...) +AC_INIT(Valgrind, 3.0.1, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE |
|
From: <sv...@va...> - 2005-08-29 22:49:14
|
Author: njn Date: 2005-08-29 23:49:11 +0100 (Mon, 29 Aug 2005) New Revision: 188 Log: wibble Modified: trunk/devel/projects.html Modified: trunk/devel/projects.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/devel/projects.html 2005-08-29 22:33:11 UTC (rev 187) +++ trunk/devel/projects.html 2005-08-29 22:49:11 UTC (rev 188) @@ -125,7 +125,7 @@ </ul> =20 <p>Fixing these gaps is not very hard, just tedious. (Added August 27, -2005)<p> +2005)</p> =20 <h3>Unit regression tests</h3> <p>The regression tests are good system-level tests, but we have almost = no unit |
|
From: Nicholas N. <nj...@cs...> - 2005-08-29 22:38:11
|
Hi, I've put a couple of new things on the Valgrind website that may be of interest. - http://www.valgrind.org/devel/platforms.html now has a description of our porting priorities for Valgrind. - http://www.valgrind.org/devel/projects.html has a list of project suggestions for anyone interested in contributing to Valgrind. It includes suggestions for Valgrind features, software infrastructure improvements (eg. regression testing) and possible research projects. Feedback and further ideas are welcome! Nick |
|
From: <sv...@va...> - 2005-08-29 22:33:16
|
Author: njn Date: 2005-08-29 23:33:11 +0100 (Mon, 29 Aug 2005) New Revision: 187 Log: tweaks Modified: trunk/devel/projects.html trunk/support/contributing.html Modified: trunk/devel/projects.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/devel/projects.html 2005-08-29 22:31:00 UTC (rev 186) +++ trunk/devel/projects.html 2005-08-29 22:33:11 UTC (rev 187) @@ -79,10 +79,10 @@ but they are not free.</p></li> =20 <li><p>Artificial programs that stress performance-critical subsystems. - For example http://bugs.kde.org/show_bug.cgi?id=3D105039 has an exampl= e - program that does many malloc and free calls, and has many heap blocks - live at one time. This exposed a performance bug in Valgrind's heap - allocator.</p></li> + For example <a href=3D"http://bugs.kde.org/show_bug.cgi?id=3D105039">b= ug + report #105039</a> has an example program that does many malloc and + free calls, and has many heap blocks live at one time. This exposed a + performance bug in Valgrind's heap allocator.</p></li> </ol> =20 <p>The scripts in nightly/ for doing the nightly regression tests would = be the Modified: trunk/support/contributing.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/support/contributing.html 2005-08-29 22:31:00 UTC (rev 186) +++ trunk/support/contributing.html 2005-08-29 22:33:11 UTC (rev 187) @@ -15,7 +15,7 @@ patches that help in this respect are welcome. Please send them to the <?php echo vglink( 'vgdevel' ); ?> list.</p> =20 -<h3>Software Infrastructure and Code</h3> +<h3>Software Infrastructure, Code and Research</h3> If you are interested in writing code for Valgrind itself or its infrastructure, or doing research with it, please consult our <a href=3D"/devel/projects.html">project suggestions</a> page. |
|
From: <sv...@va...> - 2005-08-29 22:31:02
|
Author: njn
Date: 2005-08-29 23:31:00 +0100 (Mon, 29 Aug 2005)
New Revision: 186
Log:
whoops
Modified:
trunk/php/menu.php
Modified: trunk/php/menu.php
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/php/menu.php 2005-08-29 22:30:32 UTC (rev 185)
+++ trunk/php/menu.php 2005-08-29 22:31:00 UTC (rev 186)
@@ -35,8 +35,8 @@
$devel =3D array(
array( 'url'=3D>'platforms.html', 'tag'=3D>'Supported Platforms' ),
array( 'url'=3D>'cvs_svn.html', 'tag'=3D>'SVN Repos' ),
- array( 'url'=3D>'guis.html', 'tag'=3D>'Front Ends / GUIs' )
- array( 'url'=3D>'projects.html', 'tag'=3D>'Project Suggestions' )*=
/
+ array( 'url'=3D>'guis.html', 'tag'=3D>'Front Ends / GUIs' ),
+ array( 'url'=3D>'projects.html', 'tag'=3D>'Project Suggestions' )
/*array( 'url'=3D>'consultants.html', 'tag'=3D>'Commercial Support' )=
*/
);
=20
|
|
From: <sv...@va...> - 2005-08-29 22:30:36
|
Author: njn Date: 2005-08-29 23:30:32 +0100 (Mon, 29 Aug 2005) New Revision: 185 Log: Added a "project suggestions" page. Added: trunk/devel/projects.html Modified: trunk/php/menu.php trunk/support/contributing.html Added: trunk/devel/projects.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/devel/projects.html 2005-08-29 22:30:12 UTC (rev 184) +++ trunk/devel/projects.html 2005-08-29 22:30:32 UTC (rev 185) @@ -0,0 +1,417 @@ + +<h1>Project Suggestions</h1> + +<p>This page gives a list of Valgrind projects that people might like to +try. They range from quite easy hacking projects to research-level +problems. If you plan to try one of these projects, you should +subscribe to <?php echo vglink( 'vgdevel' ); ?> list, and also write to +it to let us know you are doing the project, and you can ask questions +there also.</p> + +<p>Please note that we are very conservative about adding new features. +Only features that are useful to many users, and that do not adversely +affect the maintainability or correctness of the code base in adverse +ways are likely to be accepted. If you want to implement a feature not +mentioned on the following list, please ask on the valgrind-developers +list if it is likely to be incorporated before starting.</p> + +<p>Also, please understand that there is no guarantee that code you +write will be incorporated into Valgrind. It depends on a number of +factors: how well written it is, how important are the issues it +addresses, how does it affect the code base's structure, and so on. +Such is the nature of all free software projects. However, if you +consistently submit high quality patches, you may be granted write +access to the repository. This is how most of the current developers got +involved with Valgrind.</p> + +<h2>Software Infrastructure</h2> + +<h3>Profiling Valgrind</h3> +<p>We haven't had a good way to profile Valgrind for something like 2 ye= ars. +If we could find a way to profile Valgrind, there would certainly be som= e +easy speed-ups to find. That would make everybody happier!</p> + +<p>Valgrind used to have a tick-based profiler. A timer was set up to s= end +SIGALRM 100 times per second, and every time it was caught Valgrind woul= d +record where in its code it was. This gave a good view of which parts o= f +the code were responsible for the most amount of runtime. The code for = this +is still there (see coregrind/m_profile.c) but it hasn't worked for a lo= ng +time. If you activate it (set VG_DO_PROFILING in include/pub_tool_profi= le.h, +recompile, and use --profile=3Dyes) Valgrind bombs due to signal issues. +Also, this relies on the glibc function setitimer(), and we are in the +process of removing all dependencies on glibc.</p> + +<p>Neither gcov nor gprof work with Valgrind, basically because Valgrind= does +weird stuff that they cannot handle. Perhaps another tool (OProfile?) w= ould +be appropriate.</p> + +<p>Using Cachegrind is a possibility, although Valgrind's support for ru= nning +itself is very flaky at the moment. Improving this support would also l= et +us run Valgrind itself under Memcheck.</p> + +<p>Or if anyone knows how to get the tick-based profiler working again +without relying on glibc functions, that would be a good start. (Added +August 27, 2005)</p> + + +<h3>Performance regression testing</h3> +<p>We currently have some scripts to run the regression tests nightly on +a range of machines. This is very useful for spotting correctness +regressions. Equally useful would be a system for spotting performance +regressions (or improvements).</p> + +<p>This would involve running the Valgrind tools on a given suite of +programs, and recording how long they take to run. Or, perhaps better +would be recording how much slower than normal the programs run under +Valgrind; that metric would be more robust if the compiler or system +libraries on the test machine changed.</p> + +<p>The nightly measurements should be kept and ideally there would be a +system for producing graphs that show the performance changes over time. +You'd have to specify somehow where the previous measurements would be +stored, perhaps that would be a command line argument to the script.</p> + +<p>Choosing the programs for the test suite would be challenging. +Ideally we'd have a mix of two kinds of programs:</p> + +<ol> +<li><p>Real programs. Ones like the SPEC2000 benchmarks would be ideal, + but they are not free.</p></li> + =20 +<li><p>Artificial programs that stress performance-critical subsystems. + For example http://bugs.kde.org/show_bug.cgi?id=3D105039 has an exampl= e + program that does many malloc and free calls, and has many heap blocks + live at one time. This exposed a performance bug in Valgrind's heap + allocator.</p></li> +</ol> + +<p>The scripts in nightly/ for doing the nightly regression tests would = be the +right place to start on this. (Added August 27, 2005)</p> + + +<h3>Regression test brittleness</h3> +<p>Valgrind's regression test suite (run with "make regtest") is extreme= ly +useful. The scripts in nightly/ are used on various test machines to +determine if regressions are introduced. Unfortunately, some of the tes= ts +are too brittle -- they fail on some machines because of slight +configuration differences. On the eight test machines we use, we see up= to +about 10 or 15 failures that should not happen due to these +differences.</p> + +<p>Improving things will require either additional expected output files= (the +*.stderr.exp* and *.stdout.exp* files in the tests/ directories), or mor= e +clever output filters (the filters have names like filter_stderr). If y= ou +attempt to improve the filters, you should be careful not to remove so m= uch +information that the test becomes weaker. (Added August 27, 2005)</p> + + +<h3>Regression test gaps</h3> +<p>The regression tests are great, but they have some gaps. For +example:</p> + +<ul> +<li><p>The auto-generated insn*.c tests in none/tests/x86/ are great: + they test almost all the x86 instructions. It would be great to have + equally comprehensive tests for the other architectures supported + (AMD64, PPC32).</p></li> + +<li><p> The test memcheck/tests/x86/scalar.c is a very thorough test for + Memcheck's checking of system call arguments. We would like similar + tests for the other platforms (AMD64, PPC32).</p></li> + +<li><p> Memcheck and Nulgrind (aka "none") have a good number of tests + each. The other tools have very few. Adding more salient tests would + be useful.</p></li> +</ul> + +<p>Fixing these gaps is not very hard, just tedious. (Added August 27, +2005)<p> + +<h3>Unit regression tests</h3> +<p>The regression tests are good system-level tests, but we have almost = no unit +testing, which is bad. We would like to pull out individual Valgrind +modules into test harnesses. These can then be tested like normal progr= ams, +using normal testing tools, such as gcov (for test coverage) and Valgrin= d +itself.</p> + +<p>The test memcheck/tests/oset_test.c is one unit test we have. It tes= ts the +m_oset module. It uses some preprocessing hacks to replace calls to +Valgrind-internal functions with calls to the standard versions, eg. cal= ling +printf() instead of VG_(printf)(). memcheck/tests/vgtest_ume.c is anoth= er +one, although it has some oddities that make it not such a good +example.</p> + +<p>(Note that when this test runs, the Valgrind built in the tree is act= ually +running and testing part of its own code! Which is quirky but fine in +practice.)</p> + +<p>Some modules will be more amenable to this approach than others; the = fewer +other modules a module depends on, the easier it is. m_oset is a case i= n +point, as it only imports 5 pub_core_* header files. Other files in +coregrind/ that would be good candidates include:</p> + +<ul> +<li>m_debuglog.c</li> +<li>m_execontext.c</li> +<li>m_hashtable.c (the test would be very similar to + m_oset.c's),</li> +<li>m_libc{assert,base,file,mman,print,proc,signal}.c</li> +<li>m_mallocfree.c (a test for this would be particularly + helpful)</li> +<li>m_stacktrace.c</li> +<li>m_syscall.c</li> +</ul> + +<p>The following would be more challenging, but perhaps still +doable:</p> + +<ul> +<li>m_stacks.c</li> +<li>m_translate.c</li> +<li>m_transtab.c</li> +<li>m_ume.c (maybe use vgtest_ume.c as a starting point, but beware + that this file will change signficantly soon)</li> +</ul> + +<p>As well as redirecting Valgrind-internal functions to glibc +equivalents, stubs for various functions would need to be written for +many of these, as is standard for unit tests.</p> + +<p>The coverage (as measured by gcov) should be as high as possible. +The coverage for m_oset.c's test is over 99%.</p> + +<p>Just fitting these tests into the existing regression test framework +means that they will only be run under Valgrind. It might also be +worthwhile to introduce a new type of regression test that should also +be run natively; this native run could use gcov to determine the test +coverage. (Added August 27, 2005)</p> + + +<h2>Coding</h2> + +<h3>Bug fixes</h3> +<p>Bug fixes are always welcome. Please consult the Bugzilla page for t= he +current bug list. Bear in mind that choosing the right bugs to fix is a= n +art, and it may be worth consulting the developers list before throwing = a +lot of effort at fixing something very obscure. Patches should be submit= ted +to the relevant Bugzilla page. (Added August 27, 2005)</p> + + +<h3>Printing floating point values</h3> +<p>Valgrind's VG_(printf)() function (in coregrind/m_debuglog.c) does +not support the %f qualifier for printing floating point numbers. In +several places (eg. in VG_(percentify)() in coregrind/m_libcprint.c) the +code prints floating point numbers in an ad hoc way. Support for the %f +qualifier would simplify things. The support probably wouldn't need to +worry about a lot of the obscure corner cases (eg. NaNs, infinities, +denormals) that complicate all things related to floating point +numbers. (Added August 27, 2005)</p> + + +<h3>Updating the C++ demangler</h3> +<p>Valgrind's C++ demangler was copied almost verbatim from GNU binutils +about 4 years ago. We have heard of one or two cases where it is +failing to demangle some symbols; it's possible that new demangling +cases have been introduced since then. It would be useful if someone +checked that the demangler is up-to-date, and fixed it if not. The +relevant Valgrind files are coregrind/m_demangle/*.c. This would be a +relatively easy project, at the same time being of benefit to a large +proportion of the Valgrind user base. (Added August 27, 2005)</p> + + +<h3>Core dumping</h3> +<p>Valgrind 2.4.0 could produce useful core dumps. This functionality +was disabled in the transition to 3.0.0. It would be useful to have it +back. This requires factoring out the x86/Linux-specific parts +suitably. The old code is in m_coredump.c, entirely commented out. +This would be fairly easy, it just requires looking up the ELF +documentation to understand how core dumps are structured. (Added Augus= t +27, 2005)</p> + + +<h3>Supporting custom allocators</h3> +<p>Valgrind has two client requests, VALGRIND_MALLOCLIKE_BLOCK and +VALGRIND_FREELIKE_BLOCK that are intended to support custom allocators. +But they don't work very well. In particular, if you try to hand out +pieces of memory that came from a malloc() call, they don't work. You +could write new requests (give them different names) that avoid these +problems. You should test it with one or more real custom allocators to +make sure it suffices; the problems with the existing requests stem from +the fact that they weren't tested in this way. The *MEMPOOL* client +requests are there for pool-based custom allocators. Looking at them +may be instructive. This is a fairly straightforward project. (Added +August 27, 2005)</p> + + +<h3>Addrcheck and/or compressed V bit representation</h3> +<p>Memcheck more than doubles the amount of memory a program uses, due +to its V bits. Addrcheck only increases memory by 1/8th. However, +Addrcheck has not yet been converted from the 2.x to the 3.x line. The +main issue is converting it to be 64-bit clean, particularly the shadow +memory. Also, Valgrind's structure has been rearranged a lot since 2.x +and Addrcheck has bit-rotted somewhat because of this. Getting +Addrcheck working is fairly straightforward, although it would require a +good understanding of how shadow memory works.</p> + +<p>An alternative is to make Memcheck use less memory. It shadows each +byte of memory with 8 V bits and 1 A bit. However, the 8 V bits are +almost always either all 0 or all 1, so there is great potential for +compressing the representation. Each byte could be shadowed by 2 bits, +with the following meanings:</p> + +<ul> +<li>00: unaddressable (but treated as defined; see the Memcheck + USENIX paper for details why);</li> +<li>01: addressable but all 8 bits are undefined;</li> +<li>10: addressable and all 8 bits are defined;</li> +<li>11: something else.</li> +</ul> + +<p>A secondary table would be needed for the "something else" case; it +would map memory addresses to V-bit/A-bit values. The OSet structure +(see include/pub_tool_oset.h) would be good for this.</p> + +<p>Hopefully this can be implemented with a negligible slow-down, since +the "something else" case is so rare. And the big advantage is the +large reduction in the amount of address space used, which is +particularly important on 32-bit machines such as x86. If compressed V +bits work well, we could probably get rid of Addrcheck altogether, since +the reduced memory usage is the main advantage it has over Memcheck. (A= dded +August 27, 2005)</p> + + +<h3>Preserving debugging information</h3> +<p>Currently, Valgrind unloads debugging information for shared objects +when they are unloaded with dlclose(). If the shared object has a +memory leak, the stack trace for Memcheck's error message at termination +will be missing entries, which makes fixing the leak difficult. This is +described in <a href=3D"http://bugs.kde.org/show_bug.cgi?id=3D79362">bug +report #79362</a>.</p> + +<p>One way to fix this would be to change things so that Valgrind +records source-level information for stack traces, rather than code +addresses. It is not entirely clear how to do this in a way that avoids +unnecessary debug information lookups, and nor how to avoid increasing +the amount of memory used. An implementation would help clarify the +problem and show if this approach is feasible. This project is of +intermediate difficulty. (Added August 27, 2005)</p> + + +<h3>Ports to new platforms</h3> +<p>If you are interested in porting Valgrind to a new platform, please +read <a href=3D"/devel/platforms.html#porting_plans">porting priorities +statement</a>. Note that porting is a big task and requires a great +deal of knowledge about the targeted operating system and architecture. +(Added August 27, 2005)</p> + + +<h2>Research</h2> + +<h3>Memcheck V-bit verification</h3> +<p>Nobody has ever properly tested how reliably Memcheck tracks +definedness (V bits) through complicated integer operations, nor whether +all shadow memory load/store operations work right when you take into +account all permutations of operation size, alignment and endianness. +It would be useful to have a more formal idea of the properties of the +scheme. (An interesting case: there are two forms of V bit computation +for addition, an exact one that Memcheck uses in certain crucial cases, +and an approximation one that is used most of the time.)</p> + +<p>Cryptographic algorithms -- which do a lot of bit twiddling and have +very long chains of dependent computations -- might be a good starting +point (you could run a crypto algorithm with completely defined input, +then run it gain with one undefined bit in the input, etc). The +Memcheck USENIX paper describes Memcheck's operations in some detail. +This could be a relatively easy, yet interesting, starter project, +suitable for an advanced project for an undergraduate student. (Added +August 27, 2005)</p> + + +<h3>Characterising the kernel interface</h3> +<p>The interface between Valgrind and the OS kernel is complex and +important. System calls, signals, threads and memory layout are all +involved. A document that carefully described all the interactions +would be very useful, and might lead to improvements in the +implementation. This would not be easy, but would be a great way to +learn about OS kernels and Valgrind's internals. (Added August 27, 2005.= )</p> + + +<h3>Identifying root causes of undefined value errors</h3> +<p>Memcheck's undefined value errors report the use of undefined values +at the point at which they could affect the program's behaviour. This +is often far from the root cause of the error, which often makes fixing +these errors challenging. The Memcheck USENIX paper has lots more +information about this.</p> + +<p>Typically the root cause is forgetting to initialise a piece of +memory such as a field in a struct. Some errors have more than one root +cause. If you could associate extra metadata with each undefined value +that identifies one of its root causes, better undefined error messages +would be possible. The hard part is maintaining that extra metadata for +all undefined value errors without taking a large performance hit. +We're not convinced it's even possible, but we'd love to be proven +wrong. A solution to this problem would be publishable. (Added August = 27, +2005)</p> + + +<h3>Cryptographic snooping</h3> +<p>Since a Valgrind tool can see every operation performed by a program, +it is conceivable that a tool might be able to analyse some kind of +cryptographic program as it runs to extract certain secret information, +such as a key. This may not be true at all, but it's an intriguing +thought. Assuming there is some truth to it, this might make a good +research project for an honours undergraduate or Masters student, and +could well be publishable if done well. (Added August 27, 2005)</p> + + +<h3>Detecting dangerous floating point inaccuracies</h3> +<p>Floating point arithmetic is difficult to get right. It is easy to +write programs whose outcome depend on incorrect assumptions about +levels of precision. One could imagine a tool that tracks this +precision somehow, eg. by tracking each floating point value with a +plus/minus, and then complains if the program does an operation that +relies on more precision than is present.</p> + +<p>The exact details of how this would work remain unclear. It would +require a good knowledge of how floating point arithmetic works. Also, +Vex only provides 64-bit floating point accuracy, when x86 machines +provide 80-bit floating point values; this would complicate things +further.</p> + +<p>This is a challenging project that might be suitable for part of a +Masters or PhD project. It would definitely be publishable if done +well. (Added August 27, 2005)</p> + + +<h3>A better memory profiler</h3> +<p>Many memory profilers exist that can tell you how much memory your +program uses; the Valgrind tool Massif is one example. Other profilers +can tell you about the cache utilisation of a program; Cachegrind is an +example.</p> + +<p>What other kinds of information about memory use might be useful? +How else does memory use affect program performance? Perhaps measuring +memory bandwidth use in some way would be useful -- does the program +access memory in an even fashion, or is it bursty? When one part of a +program writes values in memory and another part reads them, that area +of memory can be thought of as a communication channel between the two +fragments of code. Is it possible to construct a tool which measures +these through-memory communication rates between parts of a program?</p> + +<p>Can a tool identify inefficient uses of memory, such as copying +values around unnecessarily? Perhaps a tool that measures page faults +and helps programmers avoid them would be useful.</p> + +<p>The first step is to identify what information a programmer would +like to know to improve a program's memory usage. This is harder than +it sounds. Analysing large programs that use memory intensively would +be a good starting point. The next step is to work out how a tool can +provide this information, or a good approximation of it, reasonably +efficiently.</p> + +<p>This is all quite speculative, but I think there is a new kind of +memory profiler waiting to be invented, and Valgrind would provide an +excellent platform for developing it. These questions could form part +of a Masters or PhD project. It would certainly be publishable if done +well. (Added August 27, 2005)</p> + Modified: trunk/php/menu.php =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/php/menu.php 2005-08-29 22:30:12 UTC (rev 184) +++ trunk/php/menu.php 2005-08-29 22:30:32 UTC (rev 185) @@ -36,6 +36,7 @@ array( 'url'=3D>'platforms.html', 'tag'=3D>'Supported Platforms' ), array( 'url'=3D>'cvs_svn.html', 'tag'=3D>'SVN Repos' ), array( 'url'=3D>'guis.html', 'tag'=3D>'Front Ends / GUIs' ) + array( 'url'=3D>'projects.html', 'tag'=3D>'Project Suggestions' )*= / /*array( 'url'=3D>'consultants.html', 'tag'=3D>'Commercial Support' )= */ ); =20 Modified: trunk/support/contributing.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/support/contributing.html 2005-08-29 22:30:12 UTC (rev 184) +++ trunk/support/contributing.html 2005-08-29 22:30:32 UTC (rev 185) @@ -10,48 +10,16 @@ about writing good bug reports. Small sample programs that exhibit a bu= g are particularly helpful.</p> =20 -<h3>Testing</h3> -<p>If you can regularly test Valgrind on a range of different systems, t= hat -can be very helpful. Please contact the <?php echo vglink( 'vgdevel' ); = ?>=20 -list for more information.</p> - <h3>Documentation</h3> </p>Valgrind's documentation is not always kept up to date. Any documen= tation patches that help in this respect are welcome. Please send them to the <?php echo vglink( 'vgdevel' ); ?> list.</p> =20 -<h3>Code</h3> -<p>If you want to contribute new code to Valgrind, you should subscribe = to -the <?php echo vglink( 'vgdevel' ); ?> list.</p> +<h3>Software Infrastructure and Code</h3> +If you are interested in writing code for Valgrind itself or its +infrastructure, or doing research with it, please consult our +<a href=3D"/devel/projects.html">project suggestions</a> page. =20 -<p>There are various kinds of code you can contribute.</p> -<ul> -<li>Bug fixes are always welcome. Please consult the Bugzilla page for = the - current bug list. Patches should be submitted to the relevant Bugzi= lla - page.</li> - -<li>Ports to new platforms are also welcome. Note that porting is a big - task, and so it is worth asking on the - <?php echo vglink( 'vgdevel' ); ?> list - first if anyone else is working on a port to your chosen platform. - Ports require a very good knowledge of the platform you are porting = to. - Ports to widely used platforms are preferable.</li> - -<li>We are very conservative about adding new features. Only features - that are useful to many users, and that do not affect the code base = in - adverse ways are likely to be accepted. If you want to add a featur= e, - it is worth asking on the <?php echo vglink( 'vgdevel' ); ?> list if= it - is likely to be incorporated before starting.</li> -</ul> - -<p>Please understand that there is no guarantee that code you write will= be -incorporated into Valgrind. It depends on a number of factors: how well -written it is, how important are the issues it addresses, how does it af= fect -the code base's structure, and so on. Such is the nature of all free -software projects. However, if you consistently submit high quality -patches, you may be granted write access to the repository. This is how -most of the current developers got involved with Valgrind.</p> - <h3>Money</h3> <p>Donations are welcome, large or small. They help pay day-to-day running costs, such as bandwidth, web-hosting, electricity, and hardware |
|
From: <sv...@va...> - 2005-08-29 22:30:14
|
Author: njn Date: 2005-08-29 23:30:12 +0100 (Mon, 29 Aug 2005) New Revision: 184 Log: wibble Modified: trunk/info/about.html Modified: trunk/info/about.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/info/about.html 2005-08-29 08:09:05 UTC (rev 183) +++ trunk/info/about.html 2005-08-29 22:30:12 UTC (rev 184) @@ -113,11 +113,10 @@ more than make up for it.</p> =20 =20 -<h2>When to use Valgrind?</h2> +<h2>When should you use Valgrind?</h2> =20 -<p>When should you use Valgrind tools? It depends on your exact -needs. Here are some examples of when people use Valgrind's -error-finding tools.</p> +<p>It depends on your exact needs. Here are some examples of when +people use Valgrind's error-finding tools.</p> =20 <ul> =20 |
|
From: <sv...@va...> - 2005-08-29 22:24:22
|
Author: njn Date: 2005-08-29 23:24:20 +0100 (Mon, 29 Aug 2005) New Revision: 4572 Log: minor things Modified: trunk/docs/internals/3_0_BUGSTATUS.txt trunk/docs/internals/release-HOWTO.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/3_0_BUGSTATUS.txt 2005-08-29 22:21:36 UTC (rev 4= 571) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-29 22:24:20 UTC (rev 4= 572) @@ -334,8 +334,13 @@ FIXED-TRUNK: TODO... partial(vg:4473) FIXED-30BRANCH: TODO =20 +---------------------------------------------------------------- +n-i-bz Jeroen's XML-to-text FAQ.xml translator =20 +FIXED-TRUNK: TODO +FIXED-30BRANCH: TODO =20 + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Bugs of note not targeted for any particular release =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Modified: trunk/docs/internals/release-HOWTO.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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.txt 2005-08-29 22:21:36 UTC (rev 4= 571) +++ trunk/docs/internals/release-HOWTO.txt 2005-08-29 22:24:20 UTC (rev 4= 572) @@ -103,6 +103,8 @@ - Change release number in AC_INIT() in configure.in to "X.Y.Z.SVN", whe= re X.Y.Z is one more than the release just done. =20 +- Add a new section to docs/internals/X_Y_BUGSTATUS.txt. + - Announce the release: - Email valgrind-users, valgrind-developers, and valgrind-announce. - Email Linux Weekly News. |
|
From: <sv...@va...> - 2005-08-29 22:21:39
|
Author: njn Date: 2005-08-29 23:21:36 +0100 (Mon, 29 Aug 2005) New Revision: 4571 Log: Completely restructured this file (don't bother trying to read the diff). It's now laid out according to which release(s) a bug is targeted for, ie. which release(s) we want to fix it by. Eg. 3.0.1 and 3.1.0, or 3.1.0 only. This is more useful than grouping the bugs by when they were reported. Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/3_0_BUGSTATUS.txt 2005-08-29 13:45:48 UTC (rev 4= 570) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-29 22:21:36 UTC (rev 4= 571) @@ -1,462 +1,392 @@ +nb: "n-i-bz" =3D=3D "not in Bugzilla" =20 ------------------------------------------------------------------------- ---- Bugs known prior to 3.0.0 --- ------------------------------------------------------------------------- - -x86 INT/INT3 - -Not started. Seems low priority. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs targeted for 3.1.0 only = =3D=3D=3D +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +109861 amd64 hangs at startup +110301 ditto =20 -87263 x86 segment stuff +Will fix in 3.1. Long delay seems to be caused by amd64-Gentoo kernel +not liking large mmap/munmap requests. =20 -Not started. Seems low priority. +FIXED-TRUNK: TODO (background hacking is in progress) =20 -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +109323 ppc32: dispatch.S uses Altivec insn, which doesn't work on POWER= .=20 =20 -88116 x86 enter variants assert +Should fix for 3.1. Any fix would be similar to that for 110274. =20 -Not started. Seems low priority. +FIXED-TRUNK: TODO =20 -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +109345 ppc32 ptrace patch available should be applied =20 -96542 x86 16-bit pop insns +FIXED-TRUNK: TODO =20 -Not started. Seems low priority. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110183 tail of page with _end =20 -109861 amd64 hangs at startup -110301 ditto +Could be a problem for glibc developers. Consider fixing. =20 -Will fix in 3.1. Long delay seems to be caused by amd64-Gentoo kernel -not liking large mmap/munmap requests. +FIXED-TRUNK: TODO? =20 -FIXED-TRUNK: no (background hacking is in progress) -FIXED-30BRANCH: won't (3.1 fix only) - ---------------------------------------------------------------- +110204 fmemopen false +ve =20 -109313 x86 cmpxchg8b -110505 ditto +Seems low priority. =20 -This ought to be fixed for 3.0.1. +FIXED-TRUNK: TODO? =20 -FIXED-TRUNK: done(1331, 4390 contains regtest=20 - + mistaken commit of this file) -FIXED-30BRANCH: done(1337) - ---------------------------------------------------------------- +110205 sigcancel unwind fails =20 -109323 ppc32: dispatch.S uses Altivec insn, which doesn't work on POWER.= =20 +Tom is considering this. It would be nice to fix it for 3.1 but +status currently unclear. =20 -Should fix for 3.1. Any fix would be similar to that for 110274. +FIXED-TRUNK: vex:1320 - vex impl of sysenter + vg:4337 - minimal Valgrind-side; does not do anything =20 -FIXED-TRUNK: TODO -FIXED-30BRANCH: won't (3.1 fix only) - ---------------------------------------------------------------- +110536 Valgrind crashes when trying to realloc memory =20 -109345 ppc32 ptrace patch available should be applied +Uninvestigated. =20 FIXED-TRUNK: TODO -FIXED-30BRANCH: won't (3.1 fix only) =20 ---------------------------------------------------------------- +n-i-bz Give more info about seginfo dropping. =20 -CrispinF x86 %eflags.ac problem +FIXED-TRUNK: vg:4425 =20 -FIXED-TRUNK: yes (1319/4334) -FIXED-30BRANCH: yes (1326, and 4334 was copied across as part of 4364) =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs targeted for 3.1.0 and 3.0.1 = =3D=3D=3D +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +101204 noisy warning =20 -Give more info about seginfo dropping. +FIXED-TRUNK: vg:4511 +FIXED-30BRANCH: vg:4561 =20 -FIXED-TRUNK: yes (4425) -FIXED-30BRANCH: no - ------------------------------------------------------------------------- ---- Bugs reported after 3.0.0 shipped --- ------------------------------------------------------------------------- - -110102 dis_op2_E_G(amd64) - -FIXED-TRUNK: yes (1318) -FIXED-30BRANCH: yes (1325) - ---------------------------------------------------------------- +109313 x86 cmpxchg8b =20 -110183 tail of page with _end +FIXED-TRUNK: vex:1331, vg:4390 contains regtest=20 + + mistaken commit of this file) +FIXED-30BRANCH: vex:1337 =20 -Could be a problem for glibc developers. Consider fixing. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110102 dis_op2_E_G(amd64) =20 -110201 x86 FXTRACT +FIXED-TRUNK: vex:1318 +FIXED-30BRANCH: vex:1325 =20 -Could fix if important. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- - 110202 x86 sys_waitpid(#286) =20 -FIXED-TRUNK: fixed(r4329) -FIXED-30BRANCH: fixed(r4332) +FIXED-TRUNK: vg:4329 +FIXED-30BRANCH: vg:4332 =20 ---------------------------------------------------------------- - 110203 clock_getres(,0) =20 -FIXED-TRUNK: fixed(r4328) -FIXED-30BRANCH: fixed(r4332) +FIXED-TRUNK: vg:4328 +FIXED-30BRANCH: vg:4332 =20 ---------------------------------------------------------------- +110208 execve fail wrong retval =20 -110204 fmemopen false +ve +FIXED-TRUNK: vg:4330 +FIXED-30BRANCH: vg:4332 =20 -Seems low priority. +---------------------------------------------------------------- +110274 SSE1 now mandatory for x86 =20 -FIXED-TRUNK: no -FIXED-30BRANCH: no +FIXED-TRUNK: vex:1321, vg:4339 +FIXED-30BRANCH: vex:1327, vg:4374 =20 ---------------------------------------------------------------- +110388 amd64 0xDD 0xD1 =20 -110205 sigcancel unwind fails +FIXED-TRUNK: vex:1322 +FIXED-30BRANCH: vex:1328 =20 -Tom is considering this. It would be nice to fix it for 3.1 but -status currently unclear. +---------------------------------------------------------------- +110464 amd64 0xDC 0x1D FCOMP =20 -FIXED-TRUNK: 1320 - vex impl of sysenter - 4337 - minimal Valgrind-side; does not do anything -FIXED-30BRANCH:=20 +FIXED-TRUNK: vex:1323 +FIXED-30BRANCH: vex:1329 =20 ---------------------------------------------------------------- +110478 amd64 0xF 0xD PREFETCH =20 -110207 mpn accuracy +FIXED-TRUNK: vex:1324 +FIXED-30BRANCH: vex:1330 =20 -Can't be easily fixed (x86 rounding/precision problem) -+ not convinced it's a big problem - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110591 amd64: rdtsc not implemented properly =20 -110208 execve fail wrong retval +(Also afflicts x86) =20 -FIXED-TRUNK: yes (r4330) -FIXED-30BRANCH: yes (r4332) +FIXED-TRUNK: vex:1344 (x86), vex:1346 (amd64). +FIXED-30BRANCH: vex:1354 (x86), vex:1355 (amd64). =20 ---------------------------------------------------------------- +110652 AMD64 valgrind crashes on cwtd instruction =20 -110209 --show-emwarns misses some +FIXED-TRUNK: vex:1333 +FIXED-30BRANCH: vex:1335 =20 -Tom says: The math/test-fenv.c file in the glibc source is the code in -question and I can reproduce it with that code. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction =20 -110240 x86 FP differences +FIXED-TRUNK: vex:1334 +FIXED-30BRANCH: vex:1336 =20 -really is the same as 110207; same comments apply - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba =20 -110274 SSE1 now mandatory for x86 +FIXED-TRUNK: vg:4386 +FIXED-30BRANCH: vg:4395 =20 -FIXED-TRUNK: yes(1321/4339) -FIXED-30BRANCH: yes(1327/4374) - ---------------------------------------------------------------- +110657 Small test fixes =20 -110388 amd64 0xDD 0xD1 +(1) Filter out L3 cache warning messages causing problems +(2) Stop tests/mq failing on 2.4 kernels =20 -FIXED-TRUNK: yes(1322) -FIXED-30BRANCH: yes(1328) +I suppose it would be good to apply these. They seem low risk. =20 +FIXED-TRUNK: vg:4429 +FIXED-30BRANCH: vg:4458 + ---------------------------------------------------------------- +110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) =20 -110464 amd64 0xDC 0x1D FCOMP +FIXED-TRUNK: vex:1332 +FIXED-30BRANCH: vex:1338 =20 -FIXED-TRUNK: yes(1323) -FIXED-30BRANCH: yes(1329) - ---------------------------------------------------------------- +110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) =20 -110478 amd64 0xF 0xD PREFETCH +FIXED-TRUNK: vex:1349 +FIXED-30BRANCH: vex:1356 =20 -FIXED-TRUNK: yes(1324) -FIXED-30BRANCH: yes(1330) - ---------------------------------------------------------------- +110830 configuring with --host fails to build 32 bit on 64 bit target =20 -XML <unique> printing wrong +FIXED-TRUNK: vg:4442 +FIXED-30BRANCH: vg:4459 =20 -FIXED-TRUNK: 4355,4357,4358 -FIXED-30BRANCH: 4585 - ---------------------------------------------------------------- +110875 Assertion when execve fails =20 -Dirk r4359 (amd64 syscalls from trunk) +FIXED-TRUNK: vg:4435 +FIXED-30BRANCH: vg:4457 =20 -FIXED-TRUNK: =20 -FIXED-30BRANCH: done(4359) - ---------------------------------------------------------------- +110898 opteron instructions missing: btq sbbq btsq btrq bsfq =20 -Dirk r4360 (upd email addrs from trunk) +FIXED-TRUNK: vex:1352 +FIXED-30BRANCH: vex:1357 =20 -FIXED-TRUNK: =20 -FIXED-30BRANCH: done(4360) - ---------------------------------------------------------------- +110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) =20 -110536/7/8/9/40 Valgrind crashes when trying to realloc memory +FIXED-TRUNK: vex:1343 +FIXED-30BRANCH: vex:1358 =20 -Uninvestigated. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +111006 bogus warnings from linuxthreads =20 -110591 amd64: rdtsc not implemented properly +FIXED-TRUNK: vg:4469, vg:4470 +FIXED-30BRANCH: vg:4497, vg:4498 =20 -Under consideration. (Also afflicts x86) - -FIXED-TRUNK: 1344 (x86), 1346 (amd64). -FIXED-30BRANCH: 1354 (x86), 1355 (amd64). - ---------------------------------------------------------------- +111090 Internal Error running Massif =20 -Nick r4384 (stub implementations of Addrcheck and Helgrind) +FIXED-TRUNK: vg:4492 +FIXED-30BRANCH: vg:4509 =20 -FIXED-TRUNK: done(4384) -FIXED-30BRANCH: done(4397) - ---------------------------------------------------------------- +111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 =20 -110652 AMD64 valgrind crashes on cwtd instruction +FIXED-TRUNK: vex:1341 +FIXED-30BRANCH: vex:1359 =20 -FIXED-TRUNK: done(1333) -FIXED-30BRANCH: done(1335) - ---------------------------------------------------------------- +111102 (comment #4) Fixed 64-bit unclean "silly arg" message =20 -110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction +FIXED-TRUNK: vg:4476 +FIXED-30BRANCH: vg:4502 =20 -FIXED-TRUNK: done(1334) -FIXED-30BRANCH: done(1336) - ---------------------------------------------------------------- +111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized + memory =20 -110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba +FIXED-TRUNK: vg:4549 +FIXED-30BRANCH: vg:4563 =20 -FIXED-TRUNK: done(4386) -FIXED-30BRANCH: done(4395) - ---------------------------------------------------------------- +111513 Illegal opcode for SSE instruction (x86 movups) +NB. Bug reporter did not yet verify that the fix works. =20 -110657 Small test fixes +FIXED-TRUNK: vex:1362 +FIXED-30BRANCH: vex:1367 =20 -(1) Filter out L3 cache warning messages causing problems -(2) Stop tests/mq failing on 2.4 kernels - -I suppose it would be good to apply these. They seem low risk. - -FIXED-TRUNK: 4429 -FIXED-30BRANCH: 4458 - ---------------------------------------------------------------- +111555 VEX/Makefile: CC is set to gcc =20 -110669 valgrind attach to gdb and quitting gdb hangs valgrind +FIXED-TRUNK: vex:1364, vg:4559 +FIXED-30BRANCH: vex:1365, vg:4560 =20 -Not clear if this is really a Valgrind bug. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +CrispinF x86 %eflags.ac problem =20 -110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) +FIXED-TRUNK: vex:1319/vg:4334 +FIXED-30BRANCH: vex:1326, and vg:4334 was copied across as part of vg:43= 64 =20 -FIXED-TRUNK: done(1332) -FIXED-30BRANCH: done(1338) - ---------------------------------------------------------------- +n-i-bz XML <unique> printing wrong =20 -Nick (Cachegrind should not assert when it encounters a client -request.) +FIXED-TRUNK: vg:4355,vg:4357,vg:4358 +FIXED-30BRANCH: vg:4585 =20 -FIXED-TRUNK: done(4391) -FIXED-30BRANCH: done(4393) - ---------------------------------------------------------------- +n-i-bz Dirk r4359 (amd64 syscalls from trunk) =20 -110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) +FIXED-TRUNK: =20 +FIXED-30BRANCH: vg:4359 =20 -FIXED-TRUNK: 1349 -FIXED-30BRANCH: 1356 - ---------------------------------------------------------------- +n-i-bz Dirk r4360 (upd email addrs from trunk) =20 -110770 VEX: Generated files not always updated when making valgrind +FIXED-TRUNK: =20 +FIXED-30BRANCH: vg:4360 =20 -FIXED-TRUNK: partial(4473) -FIXED-30BRANCH: TODO - ---------------------------------------------------------------- +n-i-bz Nick r4384 (stub implementations of Addrcheck and Helgrind) =20 -110830 configuring with --host fails to build 32 bit on 64 bit target +FIXED-TRUNK: vg:4384 +FIXED-30BRANCH: vg:4397 =20 -FIXED-TRUNK: 4442 -FIXED-30BRANCH: 4459 - ---------------------------------------------------------------- +n-i-bz Nick (Cachegrind should not assert when it encounters a client +request.) =20 -110875 Assertion when execve fails +FIXED-TRUNK: vg:4391 +FIXED-30BRANCH: vg:4393 =20 -FIXED-TRUNK: 4435 -FIXED-30BRANCH: 4457 - ---------------------------------------------------------------- - Updates to Memcheck manual =20 -FIXED-TRUNK: 4419, 4427, 4434 -FIXED-30BRANCH: 4455 +FIXED-TRUNK: vg:4419, vg:4427, vg:4434 +FIXED-30BRANCH: vg:4455 =20 ---------------------------------------------------------------- - Fixed broken malloc_usable_size() =20 -FIXED-TRUNK: 4439 -FIXED-30BRANCH: 4453 +FIXED-TRUNK: vg:4439 +FIXED-30BRANCH: vg:4453 =20 ---------------------------------------------------------------- +Make suppressions work for "???" lines in stacktraces. =20 -110898 opteron instructions missing: btq sbbq btsq btrq bsfq +FIXED-TRUNK: vg:4447 +FIXED-30BRANCH: vg:4451 =20 -FIXED-TRUNK: 1352 -FIXED-30BRANCH: 1357 - ---------------------------------------------------------------- +n-i-bz vex x86->IR: unhandled instruction bytes: 0x14 0x0 =20 -110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) +FIXED-TRUNK: vex:1350 (basic fix), vex:1351 (x86 adc/sbb flags thunk = fix), + vex:1353 (amd64 adc/sbb flags thunk fi= x) +FIXED-30BRANCH: vex:1360 =20 -FIXED-TRUNK: 1343 -FIXED-30BRANCH: 1358 - ---------------------------------------------------------------- +n-i-bz minor umount/fcntl wrapper fixes =20 -Make suppressions work for "???" lines in stacktraces. +FIXED-TRUNK: vg:4487 +FIXED-30BRANCH: vg:4562 =20 -FIXED-TRUNK: 4447 -FIXED-30BRANCH: 4451 - ---------------------------------------------------------------- +n-i-bz Fix XML bugs in FAQ =20 =20 -111006 bogus warnings from linuxthreads +FIXED-TRUNK: vg:4528 +FIXED-30BRANCH: vg:4564 =20 -FIXED-TRUNK: 4469, 4470 -FIXED-30BRANCH: 4497, 4498 =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs targeted for 3.1.0 and 3.0.2 = =3D=3D=3D +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +110209 --show-emwarns misses some =20 -111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 +Tom says: The math/test-fenv.c file in the glibc source is the code in +question and I can reproduce it with that code. =20 -FIXED-TRUNK: 1341 -FIXED-30BRANCH: 1359 +FIXED-TRUNK: TODO? +FIXED-30BRANCH: TODO? =20 ---------------------------------------------------------------- +110770 VEX: Generated files not always updated when making valgrind =20 -111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized - memory +FIXED-TRUNK: TODO... partial(vg:4473) +FIXED-30BRANCH: TODO =20 -FIXED-TRUNK: 4549 -FIXED-30BRANCH: 4563 =20 ----------------------------------------------------------------- =20 -111102 (comment #4) Fixed 64-bit unclean "silly arg" message - -FIXED-TRUNK: 4476 -FIXED-30BRANCH: 4502 - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs of note not targeted for any particular release +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +n-i-bz x86 INT/INT3 =20 -not-in-bugzilla vex x86->IR: unhandled instruction bytes: 0x14 0x0 +Not started. Seems low priority. =20 -FIXED-TRUNK: 1350 (basic fix), 1351 (x86 adc/sbb flags thunk fix), - 1353 (amd64 adc/sbb flags thunk fix) -FIXED-30BRANCH: 1360 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +87263 x86 segment stuff =20 -not-in-bugzilla minor umount/fcntl wrapper fixes +Not started. Seems low priority. =20 -FIXED-TRUNK: 4487 -FIXED-30BRANCH: 4562 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +88116 x86 enter variants assert =20 -111090 Internal Error running Massif +Not started. Seems low priority. =20 -FIXED-TRUNK: 4492 -FIXED-30BRANCH: 4509 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +96542 x86 16-bit pop insns =20 -101204 noisy warning +Not started. Seems low priority. =20 -FIXED-TRUNK: 4511 -FIXED-30BRANCH: 4561 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +110201 x86 FXTRACT =20 -111513 Illegal opcode for SSE instruction (x86 movups) -NB. Bug reporter did not yet verify that the fix works. +Could fix if important. =20 -FIXED-TRUNK: 1362 -FIXED-30BRANCH: 1367 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +110207 mpn accuracy + +110240 x86 FP differences =20 -111555 VEX/Makefile: CC is set to gcc +Can't be easily fixed (x86 rounding/precision problem) ++ not convinced it's a big problem =20 -FIXED-TRUNK: 1364, 4559 -FIXED-30BRANCH: 1365, 4560 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +110669 valgrind attach to gdb and quitting gdb hangs valgrind =20 -not-in-bugzilla Fix XML bugs in FAQ =20 +Not clear if this is really a Valgrind bug. =20 -FIXED-TRUNK: 4528 -FIXED-30BRANCH: 4564 +FIXED-TRUNK: TODO? =20 |
|
From: Nicholas N. <nj...@cs...> - 2005-08-29 20:29:57
|
On Mon, 29 Aug 2005, Jeroen N. Witmond wrote: > I have put together a set of xslt files (650 lines) that can be used with > xsltproc to transform file docs/xml/FAQ.xml into the plain text version of > that file. You will find these stylesheets in the attached tarball (11KB). > There you'll also find file README.txt with more information. Ah, wonderful! You've done a very nice job of preserving the layout in the FAQ.txt file. Thanks for the detailed documentation, too. Julian has been preparing 3.0.1 today. This probably won't get into that release, but it will definitely be in the next release. Thank you very much for your effort with this, it is much appreciated. Nick |
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-29 18:34:32
|
Greetings, I have put together a set of xslt files (650 lines) that can be used with xsltproc to transform file docs/xml/FAQ.xml into the plain text version of that file. You will find these stylesheets in the attached tarball (11KB). There you'll also find file README.txt with more information. Jeroen. |
|
From: Stefan H. <st...@ho...> - 2005-08-29 14:10:24
|
sv...@va... wrote:
> Modified: branches/VALGRIND_3_0_BRANCH/NEWS
> ===================================================================
> --- branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:44:43 UTC (rev 4569)
> +++ branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:45:48 UTC (rev 4570)
> @@ -1,4 +1,62 @@
>
> +Release 3.0.1 (29 August 2005)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +3.0.1 fixes a bunch of bugs reported in 3.0.0. There is no new
> +functionality. Some of the fixed bugs are critical, so if you
> +use/distribute 3.0.0, and upgrade to 3.0.1 is recommended. The fixed
^^^
I think it should be "an upgrade".
Best regards,
Stefan
|
|
From: <sv...@va...> - 2005-08-29 13:45:50
|
Author: sewardj Date: 2005-08-29 14:45:48 +0100 (Mon, 29 Aug 2005) New Revision: 4570 Log: track changes from trunk/NEWS Modified: branches/VALGRIND_3_0_BRANCH/NEWS Modified: branches/VALGRIND_3_0_BRANCH/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:44:43 UTC (rev 4569) +++ branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:45:48 UTC (rev 4570) @@ -1,4 +1,62 @@ =20 +Release 3.0.1 (29 August 2005) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +3.0.1 fixes a bunch of bugs reported in 3.0.0. There is no new +functionality. Some of the fixed bugs are critical, so if you +use/distribute 3.0.0, and upgrade to 3.0.1 is recommended. The fixed +bugs are: + +(note: "n-i-bz" means "not in bugzilla" -- this bug does not have + a bugzilla entry). + +109313 (=3D=3D 110505) x86 cmpxchg8b +n-i-bz x86: track but ignore changes to %eflags.AC (alignment check) +110102 dis_op2_E_G(amd64) +110202 x86 sys_waitpid(#286) +110203 clock_getres(,0) +110208 execve fail wrong retval +110274 SSE1 now mandatory for x86 +110388 amd64 0xDD 0xD1 +110464 amd64 0xDC 0x1D FCOMP +110478 amd64 0xF 0xD PREFETCH +n-i-bz XML <unique> printing wrong +n-i-bz Dirk r4359 (amd64 syscalls from trunk) +110591 amd64 and x86: rdtsc not implemented properly +n-i-bz Nick r4384 (stub implementations of Addrcheck and Helgrind) +110652 AMD64 valgrind crashes on cwtd instruction +110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction +110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba +110657 Small test fixes +110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) +n-i-bz Nick (Cachegrind should not assert when it encounters a client + request.) +110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) +110830 configuring with --host fails to build 32 bit on 64 bit target +110875 Assertion when execve fails +n-i-bz Updates to Memcheck manual +n-i-bz Fixed broken malloc_usable_size() +110898 opteron instructions missing: btq btsq btrq bsfq +110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) +n-i-bz Make suppressions work for "???" lines in stacktraces. +111006 bogus warnings from linuxthreads +111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 +111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized + memory +111102 (comment #4) Fixed 64-bit unclean "silly arg" message +n-i-bz vex x86->IR: unhandled instruction bytes: 0x14 0x0 +n-i-bz minor umount/fcntl wrapper fixes +111090 Internal Error running Massif +101204 noisy warning +111513 Illegal opcode for SSE instruction (x86 movups) +111555 VEX/Makefile: CC is set to gcc +n-i-bz Fix XML bugs in FAQ =20 + +(3.0.1RC1: 29 August 05,=20 + vex/branches/VEX_3_0_BRANCH r1367,=20 + valgrind/branches/VALGRIND_3_0_BRANCH r4570). + + + Release 3.0.0 (3 August 2005) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user |