./configure, make, make install
-mechanism, and I have attempted to ensure that it works on machines
-with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover
-the vast majority of modern Linux installations.
+concentrate on what I believe to be a widely used platform: Linux on
+x86s. Valgrind uses the standard Unix ./configure,
+make, make install mechanism, and I have
+attempted to ensure that it works on machines with kernel 2.2 or 2.4
+and glibc 2.1.X or 2.2.X. This should cover the vast majority of
+modern Linux installations.
@@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of
higher optimisation levels anyway, so you don't lose much there.
-Note that as of 1 May 2002 Valgrind does not understand the DWARF
-debugging format, which is unfortunate since the upcoming gcc-3.1 uses
-it by default. Valgrind only knows about the older "stabs" format.
-If you use gcc-3.1 or above, you can still ask for stabs-format debug
-info by passing -gstabs to gcc.
+Valgrind understands both the older "stabs" debugging format, used by
+gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1
+and later.
Then just run your application, but place the word
@@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These
limits are defined in vg_include.h and can be increased
if necessary.
+
To avoid this cutoff you can use the
+--error-limit=no flag. Then valgrind will always show
+errors, regardless of how many there are. Use this flag carefully,
+since it may have a dire effect on performance.
+
+
- Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly
- buggy, so you may need to issue this flag if you use 3.0.4. A
+ Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar
+ bug, so you may need to issue this flag if you use 3.0.4. A
while later (early Apr 02) this is confirmed as a scheduling bug
in g++-3.0.4.
+
--error-limit=yes [default]--error-limit=no When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.
+
--cachesim=no [default]--cachesim=yes When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.
-
Warning: client exiting by calling exit(<number>).
- Bye!
- exit system call, which
- will immediately terminate the process. You'll get no exit-time
- error summaries or leak checks. Note that this is not the same
- as your program calling the ANSI C function exit()
- -- that causes a normal, controlled shutdown of Valgrind.
-
Warning: client switching stacks?
-
Warning: unblocking signal <number> due to
- sigprocmask
- longjmping out of the signal handler,
- and then unblocking the signal with sigprocmask
- -- a standard signal-handling idiom.
--
Warning: bad signal number <number> in __NR_sigaction.
-
Warning: set address range perms: large range <number>
$PREFIX/lib/valgrind/default.supp.
@@ -1206,8 +1197,8 @@ A brief description of the available macros:
It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.
Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.
-The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:
pthread_once and basic semaphore functions
- (sem_*) currently work.
--
-
pthread_cancel works, but instantly nukes the target
- thread without giving it any chance to clean up. Also, when a
- thread exits, it does not run any cleanup handlers.
--
pthread_once, reader-writer locks, semaphores,
+ cleanup stacks, cancellation and thread detaching currently work.
+ Various attribute-like calls are handled but ignored; you get a
warning message.
write read nanosleep
- sleep select and poll.
+ sleep select poll
+ recvmsg and
+ accept.
-
pthread_sigmask, pthread_kill,
- pthread_sigwait and raise should all now
- work as POSIX requires.
+ sigwait and raise are now implemented.
+ Each thread has its own signal mask, as POSIX requires.
+ It's a bit kludgey -- there's a system-wide pending signal set,
+ rather than one for each thread. But hey.
--prefix that
you should give to ./configure.
+
-Let me know if you have build problems.
+The configure script tests the version of the X server
+currently indicated by the current $DISPLAY. This is a
+known bug. The intention was to detect the version of the current
+XFree86 client libraries, so that correct suppressions could be
+selected for them, but instead the test checks the server version.
+This is just plain wrong.
+
+
+Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +
--I1=<size>,<associativity>,<line_size>--D1=<size>,<associativity>,<line_size>--L2=<size>,<associativity>,<line_size>diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html index 9756d3808..8c61ce495 100644 --- a/coregrind/docs/manual.html +++ b/coregrind/docs/manual.html @@ -24,9 +24,8 @@
-
./configure, make, make install
-mechanism, and I have attempted to ensure that it works on machines
-with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover
-the vast majority of modern Linux installations.
+concentrate on what I believe to be a widely used platform: Linux on
+x86s. Valgrind uses the standard Unix ./configure,
+make, make install mechanism, and I have
+attempted to ensure that it works on machines with kernel 2.2 or 2.4
+and glibc 2.1.X or 2.2.X. This should cover the vast majority of
+modern Linux installations.
@@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of
higher optimisation levels anyway, so you don't lose much there.
-Note that as of 1 May 2002 Valgrind does not understand the DWARF
-debugging format, which is unfortunate since the upcoming gcc-3.1 uses
-it by default. Valgrind only knows about the older "stabs" format.
-If you use gcc-3.1 or above, you can still ask for stabs-format debug
-info by passing -gstabs to gcc.
+Valgrind understands both the older "stabs" debugging format, used by
+gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1
+and later.
Then just run your application, but place the word
@@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These
limits are defined in vg_include.h and can be increased
if necessary.
+
To avoid this cutoff you can use the
+--error-limit=no flag. Then valgrind will always show
+errors, regardless of how many there are. Use this flag carefully,
+since it may have a dire effect on performance.
+
+
- Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.
+
--error-limit=yes [default]--error-limit=no When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.
+
--cachesim=no [default]--cachesim=yes When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.
-
Warning: client exiting by calling exit(<number>).
- Bye!
- exit system call, which
- will immediately terminate the process. You'll get no exit-time
- error summaries or leak checks. Note that this is not the same
- as your program calling the ANSI C function exit()
- -- that causes a normal, controlled shutdown of Valgrind.
-
Warning: client switching stacks?
-
Warning: unblocking signal <number> due to
- sigprocmask
- longjmping out of the signal handler,
- and then unblocking the signal with sigprocmask
- -- a standard signal-handling idiom.
--
Warning: bad signal number <number> in __NR_sigaction.
-
Warning: set address range perms: large range <number>
$PREFIX/lib/valgrind/default.supp.
@@ -1206,8 +1197,8 @@ A brief description of the available macros:
It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.
Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.
-The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:
pthread_once and basic semaphore functions
- (sem_*) currently work.
--
-
pthread_cancel works, but instantly nukes the target
- thread without giving it any chance to clean up. Also, when a
- thread exits, it does not run any cleanup handlers.
--
pthread_once, reader-writer locks, semaphores,
+ cleanup stacks, cancellation and thread detaching currently work.
+ Various attribute-like calls are handled but ignored; you get a
warning message.
write read nanosleep
- sleep select and poll.
+ sleep select poll
+ recvmsg and
+ accept.
-
pthread_sigmask, pthread_kill,
- pthread_sigwait and raise should all now
- work as POSIX requires.
+ sigwait and raise are now implemented.
+ Each thread has its own signal mask, as POSIX requires.
+ It's a bit kludgey -- there's a system-wide pending signal set,
+ rather than one for each thread. But hey.
--prefix that
you should give to ./configure.
+
-Let me know if you have build problems.
+The configure script tests the version of the X server
+currently indicated by the current $DISPLAY. This is a
+known bug. The intention was to detect the version of the current
+XFree86 client libraries, so that correct suppressions could be
+selected for them, but instead the test checks the server version.
+This is just plain wrong.
+
+
+Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +
--I1=<size>,<associativity>,<line_size>--D1=<size>,<associativity>,<line_size>--L2=<size>,<associativity>,<line_size>diff --git a/docs/manual.html b/docs/manual.html index 9756d3808..8c61ce495 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -24,9 +24,8 @@
-
./configure, make, make install
-mechanism, and I have attempted to ensure that it works on machines
-with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover
-the vast majority of modern Linux installations.
+concentrate on what I believe to be a widely used platform: Linux on
+x86s. Valgrind uses the standard Unix ./configure,
+make, make install mechanism, and I have
+attempted to ensure that it works on machines with kernel 2.2 or 2.4
+and glibc 2.1.X or 2.2.X. This should cover the vast majority of
+modern Linux installations.
@@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of
higher optimisation levels anyway, so you don't lose much there.
-Note that as of 1 May 2002 Valgrind does not understand the DWARF
-debugging format, which is unfortunate since the upcoming gcc-3.1 uses
-it by default. Valgrind only knows about the older "stabs" format.
-If you use gcc-3.1 or above, you can still ask for stabs-format debug
-info by passing -gstabs to gcc.
+Valgrind understands both the older "stabs" debugging format, used by
+gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1
+and later.
Then just run your application, but place the word
@@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These
limits are defined in vg_include.h and can be increased
if necessary.
+
To avoid this cutoff you can use the
+--error-limit=no flag. Then valgrind will always show
+errors, regardless of how many there are. Use this flag carefully,
+since it may have a dire effect on performance.
+
+
- Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.
+
--error-limit=yes [default]--error-limit=no When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.
+
--cachesim=no [default]--cachesim=yes When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.
-
Warning: client exiting by calling exit(<number>).
- Bye!
- exit system call, which
- will immediately terminate the process. You'll get no exit-time
- error summaries or leak checks. Note that this is not the same
- as your program calling the ANSI C function exit()
- -- that causes a normal, controlled shutdown of Valgrind.
-
Warning: client switching stacks?
-
Warning: unblocking signal <number> due to
- sigprocmask
- longjmping out of the signal handler,
- and then unblocking the signal with sigprocmask
- -- a standard signal-handling idiom.
--
Warning: bad signal number <number> in __NR_sigaction.
-
Warning: set address range perms: large range <number>
$PREFIX/lib/valgrind/default.supp.
@@ -1206,8 +1197,8 @@ A brief description of the available macros:
It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.
Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.
-The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:
pthread_once and basic semaphore functions
- (sem_*) currently work.
--
-
pthread_cancel works, but instantly nukes the target
- thread without giving it any chance to clean up. Also, when a
- thread exits, it does not run any cleanup handlers.
--
pthread_once, reader-writer locks, semaphores,
+ cleanup stacks, cancellation and thread detaching currently work.
+ Various attribute-like calls are handled but ignored; you get a
warning message.
write read nanosleep
- sleep select and poll.
+ sleep select poll
+ recvmsg and
+ accept.
-
pthread_sigmask, pthread_kill,
- pthread_sigwait and raise should all now
- work as POSIX requires.
+ sigwait and raise are now implemented.
+ Each thread has its own signal mask, as POSIX requires.
+ It's a bit kludgey -- there's a system-wide pending signal set,
+ rather than one for each thread. But hey.
--prefix that
you should give to ./configure.
+
-Let me know if you have build problems.
+The configure script tests the version of the X server
+currently indicated by the current $DISPLAY. This is a
+known bug. The intention was to detect the version of the current
+XFree86 client libraries, so that correct suppressions could be
+selected for them, but instead the test checks the server version.
+This is just plain wrong.
+
+
+Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +
--I1=<size>,<associativity>,<line_size>--D1=<size>,<associativity>,<line_size>--L2=<size>,<associativity>,<line_size>diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html index 9756d3808..8c61ce495 100644 --- a/memcheck/docs/manual.html +++ b/memcheck/docs/manual.html @@ -24,9 +24,8 @@
-
./configure, make, make install
-mechanism, and I have attempted to ensure that it works on machines
-with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover
-the vast majority of modern Linux installations.
+concentrate on what I believe to be a widely used platform: Linux on
+x86s. Valgrind uses the standard Unix ./configure,
+make, make install mechanism, and I have
+attempted to ensure that it works on machines with kernel 2.2 or 2.4
+and glibc 2.1.X or 2.2.X. This should cover the vast majority of
+modern Linux installations.
@@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of
higher optimisation levels anyway, so you don't lose much there.
-Note that as of 1 May 2002 Valgrind does not understand the DWARF
-debugging format, which is unfortunate since the upcoming gcc-3.1 uses
-it by default. Valgrind only knows about the older "stabs" format.
-If you use gcc-3.1 or above, you can still ask for stabs-format debug
-info by passing -gstabs to gcc.
+Valgrind understands both the older "stabs" debugging format, used by
+gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1
+and later.
Then just run your application, but place the word
@@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These
limits are defined in vg_include.h and can be increased
if necessary.
+
To avoid this cutoff you can use the
+--error-limit=no flag. Then valgrind will always show
+errors, regardless of how many there are. Use this flag carefully,
+since it may have a dire effect on performance.
+
+
- Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.
+
--error-limit=yes [default]--error-limit=no When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.
+
--cachesim=no [default]--cachesim=yes When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.
-
Warning: client exiting by calling exit(<number>).
- Bye!
- exit system call, which
- will immediately terminate the process. You'll get no exit-time
- error summaries or leak checks. Note that this is not the same
- as your program calling the ANSI C function exit()
- -- that causes a normal, controlled shutdown of Valgrind.
-
Warning: client switching stacks?
-
Warning: unblocking signal <number> due to
- sigprocmask
- longjmping out of the signal handler,
- and then unblocking the signal with sigprocmask
- -- a standard signal-handling idiom.
--
Warning: bad signal number <number> in __NR_sigaction.
-
Warning: set address range perms: large range <number>
$PREFIX/lib/valgrind/default.supp.
@@ -1206,8 +1197,8 @@ A brief description of the available macros:
It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.
Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.
-The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:
pthread_once and basic semaphore functions
- (sem_*) currently work.
--
-
pthread_cancel works, but instantly nukes the target
- thread without giving it any chance to clean up. Also, when a
- thread exits, it does not run any cleanup handlers.
--
pthread_once, reader-writer locks, semaphores,
+ cleanup stacks, cancellation and thread detaching currently work.
+ Various attribute-like calls are handled but ignored; you get a
warning message.
write read nanosleep
- sleep select and poll.
+ sleep select poll
+ recvmsg and
+ accept.
-
pthread_sigmask, pthread_kill,
- pthread_sigwait and raise should all now
- work as POSIX requires.
+ sigwait and raise are now implemented.
+ Each thread has its own signal mask, as POSIX requires.
+ It's a bit kludgey -- there's a system-wide pending signal set,
+ rather than one for each thread. But hey.
--prefix that
you should give to ./configure.
+
-Let me know if you have build problems.
+The configure script tests the version of the X server
+currently indicated by the current $DISPLAY. This is a
+known bug. The intention was to detect the version of the current
+XFree86 client libraries, so that correct suppressions could be
+selected for them, but instead the test checks the server version.
+This is just plain wrong.
+
+
+Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +
--I1=<size>,<associativity>,<line_size>--D1=<size>,<associativity>,<line_size>--L2=<size>,<associativity>,<line_size>