[Valgrind-developers] valgrind

[Nicholas N. <nj...@ca...>]

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