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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Julian S. <js...@ac...> - 2003-12-12 06:22:37
|
CVS commit by jseward:
Print "object doesn't have a %s" all on one line.
M +4 -2 vg_symtab2.c 1.61
--- valgrind/coregrind/vg_symtab2.c #1.60:1.61
@@ -677,6 +677,8 @@ void read_symtab( SegInfo* si, Char* tab
if (o_strtab == NULL || o_symtab == NULL) {
- VG_(symerr)("object doesn't have a ");
- VG_(symerr)(tab_name);
+ Char buf[80];
+ vg_assert(VG_(strlen)(tab_name) < 40);
+ VG_(sprintf)(buf, " object doesn't have a %s", tab_name);
+ VG_(symerr)(buf);
return;
}
|
|
From: Jeremy F. <je...@go...> - 2003-12-11 04:51:28
|
While playing around with helgrind, I disabled the malloc replacement, so the test was working with the libc malloc/free. This immediately started reporting races. I had thought it was because glibc doesn't bother locking unless there are multiple threads, so it should be enough to set __libc_multiple_threads = 1. It turns out that the problem is a bit more insidious than that. What actually happens is that glibc's libpthread (either linuxthreads or NPTL) actually calls a function __libc_pthread_init(), passing a structure containing pointers to pthread functions. Rather than just calling, say, pthread_mutex_lock, malloc and friends look at this structure, and call the referenced function if it is non-NULL. It seems to me that these function pointers will always be NULL in the Valgrind case, and so glibc is doing a lot of stuff unlocked. It also seems quite hard to fix. Both NPTL and linuxthreads have different versions of __libc_pthread_init() and the pthreads function structure; for each version of libc, they compile their own versions in. We can't really do the same without being fragilely version dependent. This is the first thing which really makes me think that using native pthreads is a good idea... Hm. One point in our favour - it looks like it really is only malloc which uses this stuff. Perhaps our libpthread can arrange to wrap all the malloc calls with serialization, so it isn't a problem... J |
|
From: Balaji I. <bri...@nc...> - 2003-12-10 03:21:57
|
hi, I am trying to run some bench marks on a Java VM, with the Java VM being run on valgrind (cachegrind). The cache statistics I get are exactly the same for different benchmarks. This is the command I run: #> valgrind --skin=cachegrind JVM bench_mark These benchmarks are significantly different in behaviour. Does this mean that cachegrind takes into account the execution of the JVM only and doesnt take into account the execution of the benchmark by the JVM. thanks -Balaji. |
|
From: Jeremy F. <je...@go...> - 2003-12-09 01:06:33
|
On Mon, 2003-12-08 at 13:55, Balaji Rs Iyengar wrote: > hello, > > On Mon, 8 Dec 2003, Jeremy Fitzhardinge wrote: > > > On Mon, 2003-12-08 at 11:45, Balaji Rs Iyengar wrote: > > > 1. Could you explain where this address translation is done. I looked into > > > the detailed tech notes and went through the code in vg_memory.c and I > > > have some understanding but I am not clear. > > > > Valgrind does no data address translation. Memory at location X in your > > client code will be at address X in the process itself. There is code > > address translation, of course, but I assume you're talking about data. > > > I am referring to code addresses. Sorry, I misunderstood. You want to look at the stuff in vg_transtab.c, which manages the translation table. There's only a true mapping from code addresses -> translated addresses at the start of each basic block. That said, cachesim should operate entirely in terms of your original code addresses rather than the translated addresses. J |
|
From: Jeremy F. <je...@go...> - 2003-12-08 21:59:14
|
CVS commit by fitzhardinge:
Patch from Tom Hughes: make --gdb-attach=yes work when a program is
killed by a fatal signal.
M +6 -1 vg_signals.c 1.52
--- valgrind/coregrind/vg_signals.c #1.51:1.52
@@ -1388,4 +1388,9 @@ static void vg_default_action(const vki_
}
+ if (VG_(is_action_requested)( "Attach to GDB", & VG_(clo_GDB_attach) )) {
+ ThreadState* tst = & VG_(threads)[ tid ];
+ VG_(swizzle_esp_then_start_GDB)( tst->m_eip, tst->m_esp, tst->m_ebp );
+ }
+
if (VG_(fatal_signal_set)) {
VG_(fatal_sigNo) = sigNo;
|
|
From: Jeremy F. <je...@go...> - 2003-12-08 21:49:10
|
On Mon, 2003-12-08 at 11:45, Balaji Rs Iyengar wrote: > 1. Could you explain where this address translation is done. I looked into > the detailed tech notes and went through the code in vg_memory.c and I > have some understanding but I am not clear. Valgrind does no data address translation. Memory at location X in your client code will be at address X in the process itself. There is code address translation, of course, but I assume you're talking about data. J |
|
From: Balaji Rs I. <bri...@un...> - 2003-12-08 19:45:20
|
hi,
I am trying to seggregate the percentage of hits and misses attributable
to a particular address range. To be precise I am running some bench marks
on a Java Virtual machine, for e.g.:
valgrind --skin=cachegrind --I1=8192,8,64 --D1=8192,8,64 --L2=262144,8,64 rvm -verbose
I modified the cachesim_##L##_doref function and added a data structure
to get the miss and hit counts to specific areas in the heap.
The range of addresses I am interested in, is the heap space maintained by
the JavaVM. A -v command line flag in the VM tells me these address ranges
and I use these to do the conditional checks in the cachesim_##L##_doref
function followed by the counter increments in case of misses and hits.
However from the counter values and the out file generated it is
apparent that none of the addresses passed to cache-grind are in this
range. This is not possible since these addresses are being accessed by
the Java VM. This leads me to think that this is because of the address
translation being done by valgrind.
My questions are:
1. Could you explain where this address translation is done. I looked into
the detailed tech notes and went through the code in vg_memory.c and I
have some understanding but I am not clear.
2. Given an address range A-B, is there a way to determine the range to
which this will be translated by valgrind.
Any additional pointers will be greatly appreciated.
thanks
best regards
-balaji.
On Mon, 3 Nov 2003, Nicholas Nethercote wrote:
> On Mon, 3 Nov 2003, Balaji Iyengar wrote:
>
> > i am trying to modify cachgrind so it tells me the percentage of hits
and
> > misses attributable to a particular address range. I went through the
code
> > in cg_sim_gen.c and cg_main.c and have the following questions.
> >
> > 1. #define CACHESIM(L, MISS_TREATMENT)
> > this macro is defined in cg_sim_gen.c and I am not able to
determine
> > where it is used
>
> [~/grind/head5/cachegrind] grep CACHESIM *.c
> cg_sim_D1.c:CACHESIM(D1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2);
} );
> cg_sim_gen.c:#define CACHESIM(L, MISS_TREATMENT)
\
> cg_sim_I1.c:CACHESIM(I1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2);
} );
> cg_sim_L2.c:CACHESIM(L2, (*m2)++ );
>
>
> > 2. the function: void cachesim_##L##_doref(Addr a, UChar size,
ULong* m1,
ULong *m2)
> > is defined as part of the above macro, how is the ##L## translated to
_I1_ and _D1_
>
> As Tom said, it's macro concatenation.
>
> > 3. If I have to make cachegrind except more command line arguments
such as
> > the starting address and range, wher would i make these changes.
>
> Look for variables named "clo_*" and "VG_(clo_*)" in the skins (eg.
> Cachegrind, Memcheck) for example usage. They're fairly
straightforward.
>
> > 4. Also what would help is a general description of the sequence in
which the
> > functions are called, because at this point I am totally at bay and
dont
> > quite understand what is happening where in the code.
>
> Which functions?
>
> First of all, have you read the skin-writing guide? (Section 7 of the
> manual).
>
> Once you've done that, I would try modifying Cachegrind in very small
> steps. Start by just inserting printf's in strategic places to work out
> when different things occur.
>
> However, I think for what you want, all you need is to adjust the
> cachesim_##L##_doref function -- because you don't want to change how
the
> addresses accessed are passed to the cache simulation, but rather what's
> done with those addresses within the simulation. You don't need to know
> how Cachegrind is finding those addresses. But I can understand that
you
> might want to know how it does it.
>
> > 5. Could somebody highlight a brief set of steps that is required to
do this
> > sort of thing (seggregate cache misses/hits depending on the address
space in
> > the memory )
>
> It seems there's two parts to your problem. The first is getting the
> stream of address reads and writes. The second is using them to
simulate
> the cache. Segregating the memory falls under the second, and shouldn't
> be hard -- instead of having single global counters for hit and miss
> counts, have a series of them, one per address range.
>
> Hope this helps.
>
> N
>
|
|
From: Dirk M. <mu...@kd...> - 2003-12-07 23:36:44
|
CVS commit by mueller: in C, casting of lvalues is illegal. M +1 -1 vg_syscalls.c 1.63 --- valgrind/coregrind/vg_syscalls.c #1.62:1.63 @@ -816,5 +816,5 @@ static Bool fd_allowed(Int fd, const Cha #define SYSNO (tst->m_eax) /* in PRE(x) */ -#define res ((Int)tst->m_eax) /* in POST(x) */ +#define res (tst->m_eax) /* in POST(x) */ #define arg1 (tst->m_ebx) #define arg2 (tst->m_ecx) |
|
From: Dirk M. <mu...@kd...> - 2003-12-07 23:29:20
|
CVS commit by mueller:
add some const's in strategic places to make it compile with gcc 3.4
M +3 -3 coregrind/vg_default.c 1.16.2.1
M +3 -3 coregrind/vg_include.h 1.142.2.3
M +1 -1 coregrind/vg_intercept.c 1.18.2.4
M +2 -2 coregrind/vg_libpthread.c 1.130.2.3
M +8 -8 coregrind/vg_mylibc.c 1.45.2.1
M +3 -3 include/vg_skin.h 1.79.2.5
--- valgrind/coregrind/vg_default.c #1.16:1.16.2.1
@@ -46,5 +46,5 @@
static __attribute__ ((noreturn))
-void fund_panic ( Char* fn )
+void fund_panic ( const Char* fn )
{
VG_(printf)(
@@ -57,5 +57,5 @@ void fund_panic ( Char* fn )
static __attribute__ ((noreturn))
-void non_fund_panic ( Char* fn )
+void non_fund_panic ( const Char* fn )
{
VG_(printf)(
@@ -68,5 +68,5 @@ void non_fund_panic ( Char* fn )
static __attribute__ ((noreturn))
-void malloc_panic ( Char* fn )
+void malloc_panic ( const Char* fn )
{
VG_(printf)(
--- valgrind/coregrind/vg_include.h #1.142.2.2:1.142.2.3
@@ -1025,8 +1025,8 @@ extern void VG_(restore_all_host_signals
__PRETTY_FUNCTION__), 0)))
__attribute__ ((__noreturn__))
-extern void VG_(core_assert_fail) ( Char* expr, Char* file,
- Int line, Char* fn );
+extern void VG_(core_assert_fail) ( const Char* expr, const Char* file,
+ UInt line, const Char* fn );
__attribute__ ((__noreturn__))
-extern void VG_(core_panic) ( Char* str );
+extern void VG_(core_panic) ( const Char* str );
/* VG_(brk) not public so skins cannot screw with curr_dataseg_end */
--- valgrind/coregrind/vg_intercept.c #1.18.2.3:1.18.2.4
@@ -218,5 +218,5 @@ void my_exit ( int arg )
static
-void my_assert_fail ( Char* expr, Char* file, Int line, Char* fn )
+void my_assert_fail ( const Char* expr, const Char* file, UInt line, const Char* fn )
{
char buf[1000];
--- valgrind/coregrind/vg_libpthread.c #1.130.2.2:1.130.2.3
@@ -176,5 +176,5 @@ __asm__ (
static
__attribute__((noreturn))
-void barf ( char* str )
+void barf ( const char* str )
{
char buf[1000];
@@ -222,5 +222,5 @@ void vgPlain_unimp ( char* what )
static
-void my_assert_fail ( Char* expr, Char* file, Int line, Char* fn )
+void my_assert_fail ( const Char* expr, const Char* file, UInt line, const Char* fn )
{
char buf[1000];
--- valgrind/coregrind/vg_mylibc.c #1.45:1.45.2.1
@@ -1078,5 +1078,5 @@ Bool VG_(string_match) ( Char* pat, Char
__attribute__ ((noreturn))
-static void report_and_quit ( Char* report )
+static void report_and_quit ( const Char* report )
{
VG_(pp_sched_status)();
@@ -1094,6 +1094,6 @@ static void report_and_quit ( Char* repo
__attribute__ ((noreturn))
-static void assert_fail ( Char* expr, Char* name, Char* report,
- Char* file, Int line, Char* fn )
+static void assert_fail ( const Char* expr, const Char* name, const Char* report,
+ const Char* file, UInt line, const Char* fn )
{
static Bool entered = False;
@@ -1106,5 +1106,5 @@ static void assert_fail ( Char* expr, Ch
}
-void VG_(skin_assert_fail) ( Char* expr, Char* file, Int line, Char* fn )
+void VG_(skin_assert_fail) ( const Char* expr, const Char* file, UInt line, const Char* fn )
{
assert_fail(expr, VG_(details).name, VG_(details).bug_reports_to,
@@ -1112,5 +1112,5 @@ void VG_(skin_assert_fail) ( Char* expr,
}
-void VG_(core_assert_fail) ( Char* expr, Char* file, Int line, Char* fn )
+void VG_(core_assert_fail) ( const Char* expr, const Char* file, UInt line, const Char* fn )
{
assert_fail(expr, "valgrind", VG_EMAIL_ADDR, file, line, fn);
@@ -1118,5 +1118,5 @@ void VG_(core_assert_fail) ( Char* expr,
__attribute__ ((noreturn))
-static void panic ( Char* name, Char* report, Char* str )
+static void panic ( const Char* name, const Char* report, const Char* str )
{
VG_(printf)("\n%s: the `impossible' happened:\n %s\n", name, str);
@@ -1125,10 +1125,10 @@ static void panic ( Char* name, Char* re
}
-void VG_(core_panic) ( Char* str )
+void VG_(core_panic) ( const Char* str )
{
panic("valgrind", VG_EMAIL_ADDR, str);
}
-void VG_(skin_panic) ( Char* str )
+void VG_(skin_panic) ( const Char* str )
{
panic(VG_(details).name, VG_(details).bug_reports_to, str);
--- valgrind/include/vg_skin.h #1.79.2.4:1.79.2.5
@@ -356,5 +356,5 @@ extern void VG_(exit)( Int status )
reporting info, aborts. */
__attribute__ ((__noreturn__))
-extern void VG_(skin_panic) ( Char* str );
+extern void VG_(skin_panic) ( const Char* str );
/* Looks up VG_(client_envp) */
@@ -442,6 +442,6 @@ extern Char* VG_(getcwd) ( Char* buf, In
__attribute__ ((__noreturn__))
-extern void VG_(skin_assert_fail) ( Char* expr, Char* file,
- Int line, Char* fn );
+extern void VG_(skin_assert_fail) ( const Char* expr, const Char* file,
+ UInt line, const Char* fn );
|
|
From: Dirk M. <mu...@kd...> - 2003-12-07 23:21:04
|
CVS commit by mueller:
mark it as extension
M +1 -1 valgrind.h 1.18.2.2
--- valgrind/include/valgrind.h #1.18.2.1:1.18.2.2
@@ -161,5 +161,5 @@ typedef
/* Returns 1 if running on Valgrind, 0 if running on the real CPU.
Currently implemented but untested. */
-#define RUNNING_ON_VALGRIND \
+#define RUNNING_ON_VALGRIND __extension__ \
({unsigned int _qzz_res; \
VALGRIND_MAGIC_SEQUENCE(_qzz_res, 0 /* returned if not */, \
|
|
From: Dirk M. <mu...@kd...> - 2003-12-07 23:12:35
|
CVS commit by mueller:
fix stupid typo
M +2 -2 vg_syscalls.c 1.40.2.12
--- valgrind/coregrind/vg_syscalls.c #1.40.2.11:1.40.2.12
@@ -2390,5 +2390,5 @@ void VG_(perform_assumed_nonblocking_sys
arg3, sizeof(struct rtc_time));
KERNEL_DO_SYSCALL(tid,res);
- if (!VG_(is_kerror) && res == 0)
+ if (!VG_(is_kerror)(res) && res == 0)
VG_TRACK( post_mem_write,arg3, sizeof(struct rtc_time));
break;
@@ -2402,5 +2402,5 @@ void VG_(perform_assumed_nonblocking_sys
sizeof(unsigned long));
KERNEL_DO_SYSCALL(tid,res);
- if(!VG_(is_kerror) && res == 0)
+ if(!VG_(is_kerror)(res) && res == 0)
VG_TRACK( post_mem_write,arg3, sizeof(unsigned long));
break;
|
|
From: Dirk M. <mu...@kd...> - 2003-12-05 16:40:14
|
CVS commit by mueller:
allow absolute paths to be specified when "which" is not found.
CCMAIL: 691...@bu...
M +5 -1 valgrind.in 1.40
--- valgrind/coregrind/valgrind.in #1.39:1.40
@@ -110,5 +110,9 @@
# Ensure the program exists. Ignore any error messages from 'which'.
which_prog=`which $1 2> /dev/null`
- if [ z$which_prog = z ] ; then
+ if [ z$which_prog = z ] && (echo "$1" | grep -q '/'); then
+ which_prog=$1
+ fi
+
+ if [ z$which_prog = z ]; then
echo "$0: '$1' not found in \$PATH, aborting."
exit
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-04 16:16:00
|
CVS commit by nethercote:
Fix yet more "make dist" borkage
M +1 -0 Makefile.am 1.34
--- valgrind/tests/Makefile.am #1.33:1.34
@@ -6,4 +6,5 @@
filter_addresses \
filter_discards \
+ filter_numbers \
filter_stderr_basic \
filter_test_paths
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-04 16:12:53
|
CVS commit by nethercote: Add #includes to avoid compile warnings. M +1 -1 fdleak_open.c 1.2 M +1 -1 fdleak_socketpair.c 1.2 --- valgrind/corecheck/tests/fdleak_open.c #1.1:1.2 @@ -1,4 +1,4 @@ #include <fcntl.h> - +#include <unistd.h> int main (int argc, char **argv) --- valgrind/corecheck/tests/fdleak_socketpair.c #1.1:1.2 @@ -1,4 +1,4 @@ #include <sys/socket.h> - +#include <unistd.h> int main (int argc, char **argv) |
|
From: Nicholas N. <nj...@ca...> - 2003-12-04 16:04:23
|
CVS commit by nethercote: Fix more "make dist" borkage M +1 -1 Makefile.am 1.16 --- valgrind/corecheck/tests/Makefile.am #1.15:1.16 @@ -5,5 +5,5 @@ ##--------------------------------------------------------------------------- -noinst_SCRIPTS = filter_stderr +noinst_SCRIPTS = filter_stderr filter_fdleak EXTRA_DIST = $(noinst_SCRIPTS) \ |
|
From: Nicholas N. <nj...@ca...> - 2003-12-04 15:19:14
|
CVS commit by nethercote: Added "Would you be willing to have your project mentioned on the Valgrind website" publicity question. M +9 -0 survey2 1.3 --- devel-home/valgrind/survey2 #1.2:1.3 @@ -319,4 +319,11 @@ +# Would you be willing to have your project mentioned on the Valgrind website +# as one that uses Valgrind? Please only say "yes" if you have the appropriate +# authority within your project to do so. + +yes : [ ] +no : [ ] + # Any other comments about publicity matters? @@ -339,3 +346,9 @@ # Change log #---------------------------------------------------------------------------- +$Log$ +Revision 1.3 2003/12/04 15:18:43 nethercote +Added "Would you be willing to have your project mentioned on the Valgrind +website" publicity question. + + Dec 3: added "before a release" option |
|
From: Nicholas N. <nj...@ca...> - 2003-12-04 15:14:28
|
CVS commit by nethercote:
Fix Makefile.am so "make dist" works.
M +1 -1 Makefile.am 1.15
--- valgrind/corecheck/tests/Makefile.am #1.14:1.15
@@ -22,5 +22,5 @@
pth_cvsimple.stderr.exp pth_cvsimple.stdout.exp pth_cvsimple.vgtest \
pth_empty.stderr.exp pth_empty.vgtest \
- pth_exit.stderr.exp pth_exit.stdout.exp pth_exit.vgtest \
+ pth_exit.stderr.exp pth_exit.vgtest \
pth_mutexspeed.stderr.exp \
pth_mutexspeed.stdout.exp pth_mutexspeed.vgtest \
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 23:34:06
|
CVS commit by nethercote:
More marketing.
M +10 -0 overview.html 1.8
--- devel-home/valgrind/overview.html #1.7:1.8
@@ -38,4 +38,5 @@
Slackware, Mandrake, etc.
<p>
+
<li><b>Valgrind is easy to use.</b> Valgrind uses dynamic binary
translation, so you don't need to modify, recompile or relink your
@@ -65,4 +66,5 @@
financial/banking software, operating system daemons, etc, etc.
<p>
+
<li><b>Valgrind is widely used.</b> Valgrind has been used by thousands
of programmers across the world. We have received feedback from
@@ -73,4 +75,5 @@
South Africa and Israel.
<p>
+
<li><b>Valgrind works with programs written in any language.</b>
Because Valgrind works directly with program binaries, it works with
@@ -83,4 +86,11 @@
partly or entirely in C, C++, Java, Perl, Python, x86 assembly code,
Fortran, and many others.
+ <p>
+
+<li><b>Valgrind debugs and profiles your <i>entire</i> program.</b>
+ Unlike tools that require a recompilation step, Valgrind gives you
+ total debugging and profiling coverage of every instruction executed by
+ your program, even within system libraries. You can even use Valgrind
+ on programs for which you don't have the source code.
<p>
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 23:24:09
|
CVS commit by nethercote: Added an option to survey2. M +5 -1 survey2 1.2 --- devel-home/valgrind/survey2 #1.1:1.2 @@ -85,4 +85,5 @@ after all changes : [ ] after big changes : [ ] +before a release : [ ] when a bug occurs : [ ] when a bug is suspected : [ ] @@ -335,3 +336,6 @@ # Please send completed surveys to njn25 at cam dot ac dot uk. - +#---------------------------------------------------------------------------- +# Change log +#---------------------------------------------------------------------------- +Dec 3: added "before a release" option |
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 21:46:44
|
CVS commit by nethercote:
(Mostly) merged from HEAD:
Updated the README file. It had lots of out-of-date and incorrect information
in it, much of it from 1.0.X days. Did it in such a way that if it doesn't get
touched (and it undoubtedly won't) it won't really go out of date, eg. by
removing temporary details like version numbers, dates, details of specific
software incompatibilities. It's much better to be vague but correct, than
precise but incorrect; having incorrect info in a file as important as the
README is bad. Also removed the README_KDE3_FOLKS file because it's pretty
redundant now.
Did similar, but smaller changes to README_DEVELOPERS and README_PACKAGERS.
Also updated the valgrind.spec.in file to use the new, post-1.0.X description
in the README.
Also fixed a minor omission in Addrcheck's docs.
M +1 -1 Makefile.am 1.55.2.1
M +48 -27 README 1.11.2.2
M +15 -4 README_DEVELOPERS 1.1.2.2
M +0 -2 README_PACKAGERS 1.2.8.2
M +9 -14 valgrind.spec.in 1.8.2.2
M +2 -0 addrcheck/docs/ac_main.html 1.2.4.1
R README_KDE3_FOLKS 1.3.8.1
--- valgrind/Makefile.am #1.55:1.55.2.1
@@ -39,5 +39,5 @@
FAQ.txt \
PATCHES_APPLIED ACKNOWLEDGEMENTS \
- README_KDE3_FOLKS README_PACKAGERS \
+ README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
valgrind.spec valgrind.spec.in
--- valgrind/README #1.11.2.1:1.11.2.2
@@ -1,8 +1,5 @@
-Release notes for Valgrind, version 2.0.0
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-KDE3 developers: please read also README_KDE3_FOLKS for guidance
-about how to debug KDE3 applications with Valgrind.
-
+Release notes for Valgrind
+~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are building a binary package of Valgrind for distribution,
please read README_PACKAGERS. It contains some important information.
@@ -13,20 +10,31 @@
For instructions on how to build/install, see the end of this file.
+Valgrind works on most, reasonably recent Linux setups. If you have
+problems, consult FAQ.txt to see if there are workarounds.
Executive Summary
~~~~~~~~~~~~~~~~~
-Valgrind is a tool to help you find memory-management problems in your
-programs. When a program is run under Valgrind's supervision, all
-reads and writes of memory are checked, and calls to
-malloc/new/free/delete are intercepted. As a result, Valgrind can
-detect problems such as:
-
- Use of uninitialised memory
- Reading/writing memory after it has been free'd
- Reading/writing off the end of malloc'd blocks
- Reading/writing inappropriate areas on the stack
+Valgrind is a GPL'd system for debugging and profiling x86-Linux programs.
+With the tools that come with Valgrind, you can automatically detect
+many memory management and threading bugs, avoiding hours of frustrating
+bug-hunting, making your programs more stable. You can also perform
+detailed profiling to help speed up your programs.
+
+The Valgrind distribution includes four tools: two memory error
+detectors, a thread error detector, and a cache profiler. Several other
+tools have been built with Valgrind.
+
+To give you an idea of what Valgrind tools do, when a program is run
+under the supervision of the first memory error detector tool, all reads
+and writes of memory are checked, and calls to malloc/new/free/delete
+are intercepted. As a result, it can detect problems such as:
+
+ Use of uninitialised memory
+ Reading/writing memory after it has been free'd
+ Reading/writing off the end of malloc'd blocks
+ Reading/writing inappropriate areas on the stack
Memory leaks -- where pointers to malloc'd blocks are lost forever
Passing of uninitialised and/or unaddressible memory to system calls
- Mismatched use of malloc/new/new [] vs free/delete/delete []
+ Mismatched use of malloc/new/new [] vs free/delete/delete []
Overlaps of arguments to strcpy() and related functions
Some abuses of the POSIX pthread API
@@ -34,8 +42,12 @@
Problems like these can be difficult to find by other means, often
lying undetected for long periods, then causing occasional,
-difficult-to-diagnose crashes.
-
-When Valgrind detects such a problem, it can, if you like, attach GDB
-to your program, so you can poke around and see what's going on.
+difficult-to-diagnose crashes. When one of these errors occurs, you can
+attach GDB to your program, so you can poke around and see what's going
+on.
+
+Valgrind is closely tied to details of the CPU, operating system and
+to a less extent, compiler and basic C libraries. This makes it
+difficult to make it portable, so I have chosen at the outset to
+concentrate on what I believe to be a widely used platform: x86/Linux.
Valgrind is licensed under the GNU General Public License, version 2.
@@ -47,21 +59,32 @@
A comprehensive user guide is supplied. Point your browser at
$PREFIX/share/doc/valgrind/manual.html, where $PREFIX is whatever you
-specified with --prefix= when building.
+specified with --prefix= when building.
Building and installing it
~~~~~~~~~~~~~~~~~~~~~~~~~~
+To install from CVS :
+
+ 0. Check out the code from CVS, following the instructions at
+ http://developer.kde.org/source/anoncvs.html. The 'modulename' is
+ "valgrind".
+
+ 1. cd into the source directory.
+
+ 2. Run ./autogen.sh to setup the environment (you need the standard
+ autoconf tools to do so).
+
To install from a tar.bz2 distribution:
- 1. Run ./configure, with some options if you wish. The standard
+ 3. Run ./configure, with some options if you wish. The standard
options are documented in the INSTALL file. The only interesting
one is the usual --prefix=/where/you/want/it/installed.
- 2. Do "make".
+ 4. Do "make".
- 3. Do "make install", possibly as root if the destination permissions
+ 5. Do "make install", possibly as root if the destination permissions
require that.
- 4. See if it works. Try "valgrind ls -l". Either this works,
+ 6. See if it works. Try "valgrind ls -l". Either this works,
or it bombs out complaining it can't find argc/argv/envp.
In that case, mail me a bug report.
@@ -76,4 +99,2 @@
Nick Nethercote (nj...@ca...)
Jeremy Fitzhardinge (je...@go...)
-
-5 November 2003
--- valgrind/README_DEVELOPERS #1.1.2.1:1.1.2.2
@@ -1,3 +1,18 @@
+Building and not installing it
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To run Valgrind without having to install it, run coregrind/valgrind (prefix
+with "sh" because it's not executable) with the --in-place=<dir> option, where
+<dir> is the root of the source tree (and must be an absolute path). Eg:
+
+ sh ~/grind/head4/coregrind/valgrind --in-place=/homes/njn25/grind/head4
+
+This allows you to compile and run with "make" instead of "make install",
+saving you time.
+
+I recommend compiling with "make --quiet" to further reduce the amount of
+output spewed out during compilation, letting you actually see any errors,
+warnings, etc.
+
Running the regression tests
@@ -16,7 +31,3 @@
perl tests/vg_regtest memcheck/tests/badfree.vgtest
perl tests/vg_regtest memcheck/tests/badfree
-
-
-Nick Nethercote (nj...@ca...)
-Last updated 5 November 2003
--- valgrind/README_PACKAGERS #1.2.8.1:1.2.8.2
@@ -1,5 +1,3 @@
-5 November 2003
-
Greetings, packaging person! This information is aimed at people
building binary distributions of Valgrind.
--- valgrind/valgrind.spec.in #1.8.2.1:1.8.2.2
@@ -12,18 +12,13 @@
%description
-Valgrind is a GPL'd tool to help you find memory-management problems
-in your programs. When a program is run under Valgrind's supervision,
-all reads and writes of memory are checked, and calls to
-malloc/new/free/delete are intercepted. As a result, Valgrind can
-detect problems such as:
+Valgrind is a GPL'd system for debugging and profiling x86-Linux programs.
+With the tools that come with Valgrind, you can automatically detect
+many memory management and threading bugs, avoiding hours of frustrating
+bug-hunting, making your programs more stable. You can also perform
+detailed profiling to help speed up your programs.
-- Use of uninitialised memory
-- Reading/writing memory after it has been free'd
-- Reading/writing off the end of malloc'd blocks
-- Reading/writing inappropriate areas on the stack
-- Memory leaks -- where pointers to malloc'd blocks are lost forever
-- Passing of uninitialised and/or unaddressible memory to system calls
-- Mismatched use of malloc/new/new [] vs free/delete/delete []
-- Some abuses of the POSIX Pthreads API
+The Valgrind distribution includes four tools: two memory error
+detectors, a thread error detector, and a cache profiler. Several other
+tools have been built with Valgrind.
%prep
--- valgrind/addrcheck/docs/ac_main.html #1.2:1.2.4.1
@@ -26,4 +26,6 @@
forever</li>
<li>Mismatched use of malloc/new/new [] vs free/delete/delete []</li>
+ <li>Overlapping <code>src</code> and <code>dst</code> pointers in
+ <code>memcpy()</code> and related functions</li>
<li>Some misuses of the POSIX pthreads API</li>
</ul>
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 21:45:17
|
CVS commit by nethercote:
Updated the README file. It had lots of out-of-date and incorrect information
in it, much of it from 1.0.X days. Did it in such a way that if it doesn't get
touched (and it undoubtedly won't) it won't really go out of date, eg. by
removing temporary details like version numbers, dates, details of specific
software incompatibilities. It's much better to be vague but correct, than
precise but incorrect; having incorrect info in a file as important as the
README is bad. Also removed the README_KDE3_FOLKS file because it's pretty
redundant now. Also added some changes that had been made in the stable branch
but not the HEAD.
Did similar, but smaller changes to README_DEVELOPERS and README_PACKAGERS.
Also updated the valgrind.spec.in file to use the new, post-1.0.X description
in the README.
Also fixed a minor omission in Addrcheck's docs.
MERGE TO STABLE
M +1 -1 Makefile.am 1.59
M +34 -38 README 1.15
M +0 -2 README_DEVELOPERS 1.2
M +0 -2 README_PACKAGERS 1.3
M +9 -14 valgrind.spec.in 1.10
M +2 -0 addrcheck/docs/ac_main.html 1.4
R README_KDE3_FOLKS 1.3
--- valgrind/Makefile.am #1.58:1.59
@@ -42,5 +42,5 @@
FAQ.txt \
PATCHES_APPLIED ACKNOWLEDGEMENTS \
- README_KDE3_FOLKS README_PACKAGERS \
+ README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
valgrind.spec valgrind.spec.in valgrind.pc.in
--- valgrind/README #1.14:1.15
@@ -1,8 +1,5 @@
-Release notes for Valgrind, version 1.0.0
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-KDE3 developers: please read also README_KDE3_FOLKS for guidance
-about how to debug KDE3 applications with Valgrind.
-
+Release notes for Valgrind
+~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are building a binary package of Valgrind for distribution,
please read README_PACKAGERS. It contains some important information.
@@ -13,44 +10,44 @@
For instructions on how to build/install, see the end of this file.
-Valgrind works best on systems with glibc-2.1.X or 2.2.X, and with gcc
-versions prior to 3.1. gcc-3.1 works, but generates code which causes
-valgrind to report many false errors. For now, try to use a gcc prior
-to 3.1; if you can't, at least compile your application without
-optimisation. Valgrind-1.0.X also can't handle glibc-2.3.X systems.
-
+Valgrind works on most, reasonably recent Linux setups. If you have
+problems, consult FAQ.txt to see if there are workarounds.
Executive Summary
~~~~~~~~~~~~~~~~~
-Valgrind is a tool to help you find memory-management problems in your
-programs. When a program is run under Valgrind's supervision, all
-reads and writes of memory are checked, and calls to
-malloc/new/free/delete are intercepted. As a result, Valgrind can
-detect problems such as:
-
- Use of uninitialised memory
- Reading/writing memory after it has been free'd
- Reading/writing off the end of malloc'd blocks
- Reading/writing inappropriate areas on the stack
+Valgrind is a GPL'd system for debugging and profiling x86-Linux programs.
+With the tools that come with Valgrind, you can automatically detect
+many memory management and threading bugs, avoiding hours of frustrating
+bug-hunting, making your programs more stable. You can also perform
+detailed profiling to help speed up your programs.
+
+The Valgrind distribution includes four tools: two memory error
+detectors, a thread error detector, and a cache profiler. Several other
+tools have been built with Valgrind.
+
+To give you an idea of what Valgrind tools do, when a program is run
+under the supervision of the first memory error detector tool, all reads
+and writes of memory are checked, and calls to malloc/new/free/delete
+are intercepted. As a result, it can detect problems such as:
+
+ Use of uninitialised memory
+ Reading/writing memory after it has been free'd
+ Reading/writing off the end of malloc'd blocks
+ Reading/writing inappropriate areas on the stack
Memory leaks -- where pointers to malloc'd blocks are lost forever
Passing of uninitialised and/or unaddressible memory to system calls
- Mismatched use of malloc/new/new [] vs free/delete/delete []
+ Mismatched use of malloc/new/new [] vs free/delete/delete []
+ Overlaps of arguments to strcpy() and related functions
Some abuses of the POSIX pthread API
Problems like these can be difficult to find by other means, often
lying undetected for long periods, then causing occasional,
-difficult-to-diagnose crashes.
-
-When Valgrind detects such a problem, it can, if you like, attach GDB
-to your program, so you can poke around and see what's going on.
+difficult-to-diagnose crashes. When one of these errors occurs, you can
+attach GDB to your program, so you can poke around and see what's going
+on.
Valgrind is closely tied to details of the CPU, operating system and
to a less extent, compiler and basic C libraries. This makes it
difficult to make it portable, so I have chosen at the outset to
-concentrate on what I believe to be a widely used platform: Red Hat
-Linux 7.2, on x86s. I believe that it will work without significant
-difficulty on other x86 GNU/Linux systems which use the 2.4 kernel and
-GNU libc 2.2.X, for example SuSE 7.1 and Mandrake 8.0. This version
-1.0 release is known to work on Red Hats 6.2, 7.2 and 7.3, at the very
-least.
+concentrate on what I believe to be a widely used platform: x86/Linux.
Valgrind is licensed under the GNU General Public License, version 2.
@@ -61,8 +58,6 @@
~~~~~~~~~~~~~
A comprehensive user guide is supplied. Point your browser at
-docs/index.html. If your browser doesn't like frames, point it
-instead at docs/manual.html. There's also detailed, although somewhat
-out of date, documentation of how valgrind works, in
-docs/techdocs.html.
+$PREFIX/share/doc/valgrind/manual.html, where $PREFIX is whatever you
+specified with --prefix= when building.
@@ -80,5 +75,5 @@
autoconf tools to do so).
-To install from a tar.gz archive:
+To install from a tar.bz2 distribution:
3. Run ./configure, with some options if you wish. The standard
@@ -102,3 +97,4 @@
Julian Seward (js...@ac...)
-1 July 2002
+Nick Nethercote (nj...@ca...)
+Jeremy Fitzhardinge (je...@go...)
--- valgrind/README_DEVELOPERS #1.1:1.2
@@ -1,5 +1,3 @@
-5 May 2003
-
Building and not installing it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- valgrind/README_PACKAGERS #1.2:1.3
@@ -1,5 +1,3 @@
-1 July 2002
-
Greetings, packaging person! This information is aimed at people
building binary distributions of Valgrind.
--- valgrind/valgrind.spec.in #1.9:1.10
@@ -12,18 +12,13 @@
%description
-Valgrind is a GPL'd tool to help you find memory-management problems
-in your programs. When a program is run under Valgrind's supervision,
-all reads and writes of memory are checked, and calls to
-malloc/new/free/delete are intercepted. As a result, Valgrind can
-detect problems such as:
+Valgrind is a GPL'd system for debugging and profiling x86-Linux programs.
+With the tools that come with Valgrind, you can automatically detect
+many memory management and threading bugs, avoiding hours of frustrating
+bug-hunting, making your programs more stable. You can also perform
+detailed profiling to help speed up your programs.
-- Use of uninitialised memory
-- Reading/writing memory after it has been free'd
-- Reading/writing off the end of malloc'd blocks
-- Reading/writing inappropriate areas on the stack
-- Memory leaks -- where pointers to malloc'd blocks are lost forever
-- Passing of uninitialised and/or unaddressible memory to system calls
-- Mismatched use of malloc/new/new [] vs free/delete/delete []
-- Some abuses of the POSIX Pthreads API
+The Valgrind distribution includes four tools: two memory error
+detectors, a thread error detector, and a cache profiler. Several other
+tools have been built with Valgrind.
%prep
--- valgrind/addrcheck/docs/ac_main.html #1.3:1.4
@@ -26,4 +26,6 @@
forever</li>
<li>Mismatched use of malloc/new/new [] vs free/delete/delete []</li>
+ <li>Overlapping <code>src</code> and <code>dst</code> pointers in
+ <code>memcpy()</code> and related functions</li>
<li>Some misuses of the POSIX pthreads API</li>
</ul>
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 20:39:34
|
CVS commit by nethercote: Added that Valgrind is GPL'd in a couple of prominent spots. M +2 -2 index.html 1.11 M +1 -1 overview.html 1.7 --- devel-home/valgrind/index.html #1.10:1.11 @@ -1,4 +1,4 @@ <?php - $page_title = "A system for debugging and profiling x86-Linux programs"; + $page_title = "A GPL'd system for debugging and profiling x86-Linux programs"; $page_heading = "News"; include "header.inc" @@ -11,5 +11,5 @@ <hr> <p> -<b>Valgrind is a system for debugging and profiling x86-Linux programs.</b> +<b>Valgrind is a GPL'd system for debugging and profiling x86-Linux programs.</b> With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, avoiding hours of frustrating --- devel-home/valgrind/overview.html #1.6:1.7 @@ -5,5 +5,5 @@ ?> -<b>Valgrind is a system for debugging and profiling x86-Linux programs.</b> +<b>Valgrind is a GPL'd system for debugging and profiling x86-Linux programs.</b> With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, avoiding hours of frustrating |
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 12:38:15
|
I asked this:
> > The pointer returned if the allocation succeeds is suitably aligned so
> > that it may be assigned to a pointer to any type of object and then
> > used to access such an object or an array of such objects in the
> > space allocated (until the space is explicitly freed or
> > reallocated).
> >
> > I'm not sure what this actually means. For x86, does "suitably aligned"
> > have any meaning at all, since unaligned accesses are ok?
Jeremy said:
> Well, unaligned accesses are only OK by default. You can turn on
> alignment checking, and get faults on unaligned accesses. Also, SSE
> instructions have a 16-byte alignment requirement.
>
> we should 8-align at least, maybe even 16.
Dirk said:
> suitably aligned means naturally aligned for all sizes the processor
> supports. x86 expects doubles to be 8-aligned and some SSE stuff even 16
> aligned.
"Suitably aligned" is a phrase that gets used a lot, but I can't find a
formal definition -- does anyone have one? Dirk, where did you get your
definition from?
I looked in glibc to see what happens there... it has this comment:
Alignment: 2 * sizeof(size_t) (default)
(i.e., 8 byte alignment with 4byte size_t). This suffices for
nearly all current machines and C compilers. However, you can
define MALLOC_ALIGNMENT to be wider than this if necessary.
And in practice, glibc's malloc() seems to use 8-byte alignment.
----
So, Jeremy and Dirk both said "we should use 8-byte at least, and maybe
16-byte". I agree. Since glibc uses 8-byte, that seems the best choice.
Julian, do you have any complaints?
I guess the next question is: should this change be made in just HEAD, or
stable branch too? I vote for both.
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-03 12:18:41
|
CVS commit by nethercote: Add more info to the title of each page. Also factors out more common stuff in the header. M +2 -5 bugs.html 1.7 M +2 -5 cvs.html 1.3 M +3 -6 docs.html 1.5 M +2 -5 downloads.html 1.6 M +2 -5 faq.html 1.2 M +2 -6 features.html 1.5 M +2 -6 feedback.html 1.6 M +9 -10 header.inc 1.9 M +2 -4 index.html 1.10 M +2 -5 lists.html 1.3 M +2 -5 overview.html 1.6 M +2 -5 related.html 1.3 M +3 -6 surveys.html 1.2 M +2 -5 sysreqs.html 1.5 M +2 -5 tools.html 1.4 --- devel-home/valgrind/bugs.html #1.6:1.7 @@ -1,10 +1,7 @@ <?php + $page_title = "Bug Reports"; + $page_heading = "Bug Reports"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Reporting Bugs</h2></center> Before you report a bug, please consult the --- devel-home/valgrind/cvs.html #1.2:1.3 @@ -1,10 +1,7 @@ <?php + $page_title = "CVS Repository"; + $page_heading = "CVS Repository"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>CVS Repository</h2></center> If you want a bleeding-edge version of Valgrind, follow these --- devel-home/valgrind/docs.html #1.4:1.5 @@ -1,10 +1,7 @@ <?php + $page_title = "Documentation"; + $page_heading = "Documentation"; include "header.inc" - ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Documentation</h2></center> +?> <a href="http://developer.kde.org/~sewardj/docs-2.0.0/manual.html">Full --- devel-home/valgrind/downloads.html #1.5:1.6 @@ -1,10 +1,7 @@ <?php + $page_title = "Downloads"; + $page_heading = "Downloads"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Downloads</h2></center> <h3>Current Stable Release</h3> --- devel-home/valgrind/faq.html #1.1:1.2 @@ -1,10 +1,7 @@ <?php + $page_title = "FAQ"; + $page_heading = "FAQ"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>FAQ</h2></center> <!-- FIXME : convert FAQ from valgrind CVS to html and include directly here --> --- devel-home/valgrind/features.html #1.4:1.5 @@ -1,11 +1,7 @@ <?php + $page_title = "Feature Requests"; + $page_heading = "Feature Requests"; include "header.inc" ?> - - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Feature Requests</h2></center> To request a feature, please use our --- devel-home/valgrind/feedback.html #1.5:1.6 @@ -1,11 +1,7 @@ <?php - $page_title = "Sending Feedback"; + $page_title = "Feedback"; + $page_heading = "Feedback"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Feedback</h2></center> <h3>General</h3> --- devel-home/valgrind/header.inc #1.8:1.9 @@ -2,11 +2,5 @@ <html> <head> -<?php - if (isset($page_title)) - $title = "Valgrind - $page_title"; - else - $title = "Valgrind"; -?> -<title><?php print $title; ?></title> +<title><?php print "Valgrind - $page_title"; ?></title> <link rel="stylesheet" type="text/css" href="style.css"> </head> @@ -14,9 +8,14 @@ <body> <table width="100%" cellspacing=10> -<tr><td bgcolor="#eeeeee" valign="top"> - +<tr> +<td bgcolor="#eeeeee" valign="top"> <?php include "menu.inc" ?> +</td> + +<td> +<center><h1>Valgrind</h1></center> +<hr> +<center><h2><?php print $page_heading; ?></h2></center> -</td><td> --- devel-home/valgrind/index.html #1.9:1.10 @@ -1,10 +1,8 @@ <?php + $page_title = "A system for debugging and profiling x86-Linux programs"; + $page_heading = "News"; include "header.inc" ?> -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>News</h2></center> <center>November 11, 2003: A new stable release, <a href="/downloads.html">valgrind 2.0.0</a>, is available.</center> --- devel-home/valgrind/lists.html #1.2:1.3 @@ -1,10 +1,7 @@ <?php + $page_title = "Mailing Lists"; + $page_heading = "Mailing Lists"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Mailing Lists</h2></center> The <a HREF="http://lists.sourceforge.net/lists/listinfo/valgrind-users"> --- devel-home/valgrind/overview.html #1.5:1.6 @@ -1,10 +1,7 @@ <?php + $page_title = "Overview"; + $page_heading = "Overview"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Overview</h2></center> <b>Valgrind is a system for debugging and profiling x86-Linux programs.</b> --- devel-home/valgrind/related.html #1.2:1.3 @@ -1,10 +1,7 @@ <?php + $page_title = "Related Tools"; + $page_heading = "Related Tools"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Related Tools</h2></center> <h3>Tools and Experimental Versions</h3> --- devel-home/valgrind/surveys.html #1.1:1.2 @@ -1,10 +1,7 @@ <?php + $page_title = "Surveys"; + $page_heading = "Surveys"; include "header.inc" - ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Surveys</h2></center> +?> In November 2003, we ran a survey, and got 114 responses. Thanks to all those --- devel-home/valgrind/sysreqs.html #1.4:1.5 @@ -1,10 +1,7 @@ <?php + $page_title = "System Requirements"; + $page_heading = "System Requirements"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>System Requirements</h2></center> <b>System requirements:</b> you need an x86 machine running Linux kernel --- devel-home/valgrind/tools.html #1.3:1.4 @@ -1,10 +1,7 @@ <?php + $page_title = "Tools"; + $page_heading = "Tools"; include "header.inc" ?> - -<center><h1>Valgrind</h1></center> - -<hr> -<center><h2>Tools</h2></center> The Valgrind distribution includes four useful debugging and profiling tools. |
|
From: Dirk M. <dm...@gm...> - 2003-12-03 00:09:44
|
On Tuesday 02 December 2003 01:18, Nicholas Nethercote wrote: > Thoughts? leave it as it is. VG_(clo_verbosity) wraps is good enough. |