|
From: Nicholas N. <nj...@ca...> - 2004-06-16 11:51:15
|
CVS commit by nethercote:
Removed documentation references to the 'ioctl-VTIME' and 'truncate-writes'
weird hacks, which no longer exist thanks to the proxy lwp stuff.
M +1 -1 coregrind/vg_main.c 1.153
M +0 -52 coregrind/docs/coregrind_core.html 1.28
M +1 -1 none/tests/cmdline1.stdout.exp 1.2
M +1 -1 none/tests/cmdline2.stdout.exp 1.2
--- valgrind/coregrind/vg_main.c #1.152:1.153
@@ -1521,5 +1521,5 @@ void usage ( Bool debug_help )
" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
" --weird-hacks=hack1,hack2,... [none]\n"
-" recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls\n"
+" recognised hacks are: lax-ioctls\n"
" --signal-polltime=<time> time, in mS, we should poll for signals.\n"
" Only applies for older kernels which need\n"
--- valgrind/coregrind/docs/coregrind_core.html #1.27:1.28
@@ -780,56 +780,4 @@
<p>
<ul>
- <li><code>ioctl-VTIME</code> Use this if you have a program
- which sets readable file descriptors to have a timeout by
- doing <code>ioctl</code> on them with a
- <code>TCSETA</code>-style command <b>and</b> a non-zero
- <code>VTIME</code> timeout value. This is considered
- potentially dangerous and therefore is not engaged by
- default, because it is (remotely) conceivable that it could
- cause threads doing <code>read</code> to incorrectly block
- the entire process.
- <p>
- You probably want to try this one if you have a program
- which unexpectedly blocks in a <code>read</code> from a file
- descriptor which you know to have been messed with by
- <code>ioctl</code>. This could happen, for example, if the
- descriptor is used to read input from some kind of screen
- handling library.
- <p>
- To find out if your program is blocking unexpectedly in the
- <code>read</code> system call, run with
- <code>--trace-syscalls=yes</code> flag.
- <p>
- <li><code>truncate-writes</code> Use this if you have a threaded
- program which appears to unexpectedly block whilst writing
- into a pipe. The effect is to modify all calls to
- <code>write()</code> so that requests to write more than
- 4096 bytes are treated as if they only requested a write of
- 4096 bytes. Valgrind does this by changing the
- <code>count</code> argument of <code>write()</code>, as
- passed to the kernel, so that it is at most 4096. The
- amount of data written will then be less than the client
- program asked for, but the client should have a loop around
- its <code>write()</code> call to check whether the requested
- number of bytes have been written. If not, it should issue
- further <code>write()</code> calls until all the data is
- written.
- <p>
- This all sounds pretty dodgy to me, which is why I've made
- this behaviour only happen on request. It is not the
- default behaviour. At the time of writing this (30 June
- 2002) I have only seen one example where this is necessary,
- so either the problem is extremely rare or nobody is using
- Valgrind :-)
- <p>
- On experimentation I see that <code>truncate-writes</code>
- doesn't interact well with <code>ioctl-VTIME</code>, so you
- probably don't want to try both at once.
- <p>
- As above, to find out if your program is blocking
- unexpectedly in the <code>write()</code> system call, you
- may find the <code>--trace-syscalls=yes
- --trace-sched=yes</code> flags useful.
- <p>
<li><code>lax-ioctls</code> Be very lax about ioctl handling; the only
assumption is that the size is correct. Doesn't require the full
--- valgrind/none/tests/cmdline1.stdout.exp #1.1:1.2
@@ -14,5 +14,5 @@
--run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
--weird-hacks=hack1,hack2,... [none]
- recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
+ recognised hacks are: lax-ioctls
--signal-polltime=<time> time, in mS, we should poll for signals.
Only applies for older kernels which need
--- valgrind/none/tests/cmdline2.stdout.exp #1.1:1.2
@@ -14,5 +14,5 @@
--run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
--weird-hacks=hack1,hack2,... [none]
- recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
+ recognised hacks are: lax-ioctls
--signal-polltime=<time> time, in mS, we should poll for signals.
Only applies for older kernels which need
|