]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
Get rid of the "ioctl-mmap" weird-hack flag.
authorJulian Seward <jseward@acm.org>
Wed, 28 Sep 2005 01:14:32 +0000 (01:14 +0000)
committerJulian Seward <jseward@acm.org>
Wed, 28 Sep 2005 01:14:32 +0000 (01:14 +0000)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4800

coregrind/m_main.c
docs/valgrind.1
docs/xml/manual-core.xml
none/tests/cmdline1.stdout.exp
none/tests/cmdline2.stdout.exp

index eb23a6bdc1cbf6440700d99337171104a7fa43a6..331e8bda64b2cfd95571d420b0fffc1a41b1e0f8 100644 (file)
@@ -854,7 +854,7 @@ static void usage_NORETURN ( Bool debug_help )
 "\n"
 "  uncommon user options for all Valgrind tools:\n"
 "    --run-libc-freeres=no|yes free up glibc memory at exit? [yes]\n"
-"    --weird-hacks=hack1,hack2,...  known hacks: lax-ioctls,ioctl-mmap\n"
+"    --weird-hacks=hack1,hack2,...  known hacks: lax-ioctls\n"
 "                                                enable-outer [none]\n"
 "    --pointercheck=no|yes     enforce client address space limits [yes]\n"
 "    --show-emwarns=no|yes     show warnings about emulation limits? [no]\n"
index d058fd036ac72f17c0df349f0ceb4070fdd4dae8..f303b48fbb2e7b5366d2dee60f244d13ef2aae24 100644 (file)
@@ -537,9 +537,9 @@ lax-ioctls hack tells \fBvalgrind\fP to be very lax about ioctl handling
 and assume that unknown ioctls just behave correctly.
 .TP
 .B
-- ioctl-mmap
-Tell \fBvalgrind\fP to search for new memory mappings after an unknown
-\fBioctl\fP call.
+- enable-inner
+Enable some special magic needed when the program being run is 
+itself \fBvalgrind\fP.
 .RE
 
 .SH CORE DEBUGGING OPTIONS
index f7c60e0a72025ca9d061f13cdb5997c38296dd74..68b7b44041aaed6365cb68b8025b921f3b4c5a17 100644 (file)
@@ -1024,17 +1024,13 @@ Addrcheck), the following options apply.</para>
       some device drivers with a large number of strange ioctl
       commands becomes very tiresome.</para>
      </listitem>
-     <listitem><para><computeroutput>ioctl-mmap</computeroutput></para> 
-      <para>Some ioctl requests can mmap new memory into your
-      process address space.  If Valgrind doesn't know about these mappings,
-      it could put new mappings over them, and/or complain bitterly when
-      your program uses them.  This option makes Valgrind scan the address
-      space for new mappings after each unknown ioctl has finished.  You may
-      also need to run with
-      <computeroutput>--pointercheck=no</computeroutput> if the ioctl
-      decides to place the mapping out of the client's usual address space.
+
+     <listitem><para><computeroutput>enable-inner</computeroutput></para> 
+      <para>Enable some special magic needed when the program being
+      run is itself Valgrind.
       </para>
      </listitem>
+
     </itemizedlist>
    </listitem>
 
index fada22454211bbc704ce5db0e359d9053b0ab97e..939c093bffe09291118194fa429d7c906b2afec3 100644 (file)
@@ -18,7 +18,7 @@ usage: valgrind --tool=<toolname> [options] prog-and-args
 
   uncommon user options for all Valgrind tools:
     --run-libc-freeres=no|yes free up glibc memory at exit? [yes]
-    --weird-hacks=hack1,hack2,...  known hacks: lax-ioctls,ioctl-mmap
+    --weird-hacks=hack1,hack2,...  known hacks: lax-ioctls
                                                 enable-outer [none]
     --pointercheck=no|yes     enforce client address space limits [yes]
     --show-emwarns=no|yes     show warnings about emulation limits? [no]
index ca94f0850370a689d187304f70f5fe1c64e8f957..a14ca310f4d82a8cb3ff223741b5c4675b3c7b1f 100644 (file)
@@ -18,7 +18,7 @@ usage: valgrind --tool=<toolname> [options] prog-and-args
 
   uncommon user options for all Valgrind tools:
     --run-libc-freeres=no|yes free up glibc memory at exit? [yes]
-    --weird-hacks=hack1,hack2,...  known hacks: lax-ioctls,ioctl-mmap
+    --weird-hacks=hack1,hack2,...  known hacks: lax-ioctls
                                                 enable-outer [none]
     --pointercheck=no|yes     enforce client address space limits [yes]
     --show-emwarns=no|yes     show warnings about emulation limits? [no]