From: Julian Seward Date: Tue, 16 Apr 2002 01:55:18 +0000 (+0000) Subject: Get rid of the --client-perms= flag. Valgrind now depends critically X-Git-Tag: svn/VALGRIND_1_0_3~367 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=43ca0bb6f40a4316ce44d9b37e76250ebb894f27;p=thirdparty%2Fvalgrind.git Get rid of the --client-perms= flag. Valgrind now depends critically on the client-request subsystem, and disabling it is no longer a sensible thing to do. Also: in the manual, mention flags --trace-sched= and --trace-pthread=. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@79 --- diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html index 874f7079d8..03b7ede292 100644 --- a/cachegrind/docs/manual.html +++ b/cachegrind/docs/manual.html @@ -25,6 +25,8 @@  

Valgrind, snapshot 20020324

+
This manual was minimally updated on 20020415
+

jseward@acm.org
@@ -514,89 +516,6 @@ follows: buggy, so you may need to issue this flag if you use 3.0.4.

-

  • --client-perms=no [default]
    - --client-perms=yes

    An experimental feature. -

    - When enabled, and when --instrument=yes (which is - the default), Valgrind honours client directives to set and - query address range permissions. This allows the client program - to tell Valgrind about changes in memory range permissions that - Valgrind would not otherwise know about, and so allows clients - to get Valgrind to do arbitrary custom checks. -

    - Clients need to include the header file valgrind.h - to make this work. The macros therein have the magical property - that they generate code in-line which Valgrind can spot. - However, the code does nothing when not run on Valgrind, so you - are not forced to run your program on Valgrind just because you - use the macros in this file. -

    - A brief description of the available macros: -

      -
    • VALGRIND_MAKE_NOACCESS, - VALGRIND_MAKE_WRITABLE and - VALGRIND_MAKE_READABLE. These mark address - ranges as completely inaccessible, accessible but containing - undefined data, and accessible and containing defined data, - respectively. Subsequent errors may have their faulting - addresses described in terms of these blocks. Returns a - "block handle". -

      -

    • VALGRIND_DISCARD: At some point you may want - Valgrind to stop reporting errors in terms of the blocks - defined by the previous three macros. To do this, the above - macros return a small-integer "block handle". You can pass - this block handle to VALGRIND_DISCARD. After - doing so, Valgrind will no longer be able to relate - addressing errors to the user-defined block associated with - the handle. The permissions settings associated with the - handle remain in place; this just affects how errors are - reported, not whether they are reported. Returns 1 for an - invalid handle and 0 for a valid handle (although passing - invalid handles is harmless). -

      -

    • VALGRIND_CHECK_NOACCESS, - VALGRIND_CHECK_WRITABLE and - VALGRIND_CHECK_READABLE: check immediately - whether or not the given address range has the relevant - property, and if not, print an error message. Also, for the - convenience of the client, returns zero if the relevant - property holds; otherwise, the returned value is the address - of the first byte for which the property is not true. -

      -

    • VALGRIND_CHECK_NOACCESS: a quick and easy way - to find out whether Valgrind thinks a particular variable - (lvalue, to be precise) is addressible and defined. Prints - an error message if not. Returns no value. -

      -

    • VALGRIND_MAKE_NOACCESS_STACK: a highly - experimental feature. Similarly to - VALGRIND_MAKE_NOACCESS, this marks an address - range as inaccessible, so that subsequent accesses to an - address in the range gives an error. However, this macro - does not return a block handle. Instead, all annotations - created like this are reviewed at each client - ret (subroutine return) instruction, and those - which now define an address range block the client's stack - pointer register (%esp) are automatically - deleted. -

      - In other words, this macro allows the client to tell - Valgrind about red-zones on its own stack. Valgrind - automatically discards this information when the stack - retreats past such blocks. Beware: hacky and flaky. -

    -
    • -

    - As of 17 March 02 (the time of writing this), there is a small - problem with all of these macros, which is that I haven't - figured out how to make them produce sensible (always-succeeds) - return values when the client is run on the real CPU or on - Valgrind without --client-perms=yes. So if you - write client code which depends on the return values, be aware - that it may misbehave when not run with full Valgrindification. - If you always ignore the return values you should always be - safe. I plan to fix this. There are also some options for debugging Valgrind itself. You @@ -642,6 +561,16 @@ shouldn't need to use them in the normal run of things. Nevertheless:

    Enable/disable tracing of signal handling.

    +

  • --trace-sched=no [default]
    + --trace-sched=yes +

    Enable/disable tracing of thread scheduling events.


    • +

    + +

  • --trace-pthread=no [default]
    + --trace-pthread=yes +

    Enable/disable tracing of pthread-related events.


    • +

    +

  • --trace-symtab=no [default]
    --trace-symtab=yes

    Enable/disable tracing of symbol table reading.


    • @@ -715,7 +644,7 @@ qpngio.cpp, and so on.

    Valgrind tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and -also where the block was free'd at.. Likewise, if it should turn out +also where the block was free'd at. Likewise, if it should turn out to be just off the end of a malloc'd block, a common result of off-by-one-errors in array subscripting, you'll be informed of this fact, and also where the block was malloc'd. @@ -1057,8 +986,92 @@ shell script "valgrind". On line 4, set the environment variable installation into. + +

    2.9  The Client Request mechanism

    + +Valgrind has a trapdoor mechanism via which the client program can +pass all manner of requests and queries to Valgrind. Internally, this +is used extensively to make malloc, free, signals, etc, work, although +you don't see that. +

    +For your convenience, a subset of these so-called client requests is +provided to allow you to tell Valgrind facts about the behaviour of +your program, and conversely to make queries. In particular, your +program can tell Valgrind about changes in memory range permissions +that Valgrind would not otherwise know about, and so allows clients to +get Valgrind to do arbitrary custom checks. +

    +Clients need to include the header file valgrind.h to +make this work. The macros therein have the magical property that +they generate code in-line which Valgrind can spot. However, the code +does nothing when not run on Valgrind, so you are not forced to run +your program on Valgrind just because you use the macros in this file. +

    +A brief description of the available macros: +

    + +

    + + + -

    2.9  If you have problems

    +

    2.10  If you have problems

    Mail me (jseward@acm.org).

    See Section 4 for the known limitations of diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html index 874f7079d8..03b7ede292 100644 --- a/coregrind/docs/manual.html +++ b/coregrind/docs/manual.html @@ -25,6 +25,8 @@  

    Valgrind, snapshot 20020324

    +
    This manual was minimally updated on 20020415
    +

    jseward@acm.org
    @@ -514,89 +516,6 @@ follows: buggy, so you may need to issue this flag if you use 3.0.4.

    -

  • --client-perms=no [default]
    - --client-perms=yes

    An experimental feature. -

    - When enabled, and when --instrument=yes (which is - the default), Valgrind honours client directives to set and - query address range permissions. This allows the client program - to tell Valgrind about changes in memory range permissions that - Valgrind would not otherwise know about, and so allows clients - to get Valgrind to do arbitrary custom checks. -

    - Clients need to include the header file valgrind.h - to make this work. The macros therein have the magical property - that they generate code in-line which Valgrind can spot. - However, the code does nothing when not run on Valgrind, so you - are not forced to run your program on Valgrind just because you - use the macros in this file. -

    - A brief description of the available macros: -

      -
    • VALGRIND_MAKE_NOACCESS, - VALGRIND_MAKE_WRITABLE and - VALGRIND_MAKE_READABLE. These mark address - ranges as completely inaccessible, accessible but containing - undefined data, and accessible and containing defined data, - respectively. Subsequent errors may have their faulting - addresses described in terms of these blocks. Returns a - "block handle". -

      -

    • VALGRIND_DISCARD: At some point you may want - Valgrind to stop reporting errors in terms of the blocks - defined by the previous three macros. To do this, the above - macros return a small-integer "block handle". You can pass - this block handle to VALGRIND_DISCARD. After - doing so, Valgrind will no longer be able to relate - addressing errors to the user-defined block associated with - the handle. The permissions settings associated with the - handle remain in place; this just affects how errors are - reported, not whether they are reported. Returns 1 for an - invalid handle and 0 for a valid handle (although passing - invalid handles is harmless). -

      -

    • VALGRIND_CHECK_NOACCESS, - VALGRIND_CHECK_WRITABLE and - VALGRIND_CHECK_READABLE: check immediately - whether or not the given address range has the relevant - property, and if not, print an error message. Also, for the - convenience of the client, returns zero if the relevant - property holds; otherwise, the returned value is the address - of the first byte for which the property is not true. -

      -

    • VALGRIND_CHECK_NOACCESS: a quick and easy way - to find out whether Valgrind thinks a particular variable - (lvalue, to be precise) is addressible and defined. Prints - an error message if not. Returns no value. -

      -

    • VALGRIND_MAKE_NOACCESS_STACK: a highly - experimental feature. Similarly to - VALGRIND_MAKE_NOACCESS, this marks an address - range as inaccessible, so that subsequent accesses to an - address in the range gives an error. However, this macro - does not return a block handle. Instead, all annotations - created like this are reviewed at each client - ret (subroutine return) instruction, and those - which now define an address range block the client's stack - pointer register (%esp) are automatically - deleted. -

      - In other words, this macro allows the client to tell - Valgrind about red-zones on its own stack. Valgrind - automatically discards this information when the stack - retreats past such blocks. Beware: hacky and flaky. -

    -
    • -

    - As of 17 March 02 (the time of writing this), there is a small - problem with all of these macros, which is that I haven't - figured out how to make them produce sensible (always-succeeds) - return values when the client is run on the real CPU or on - Valgrind without --client-perms=yes. So if you - write client code which depends on the return values, be aware - that it may misbehave when not run with full Valgrindification. - If you always ignore the return values you should always be - safe. I plan to fix this. There are also some options for debugging Valgrind itself. You @@ -642,6 +561,16 @@ shouldn't need to use them in the normal run of things. Nevertheless:

    Enable/disable tracing of signal handling.

    +

  • --trace-sched=no [default]
    + --trace-sched=yes +

    Enable/disable tracing of thread scheduling events.


    • +

    + +

  • --trace-pthread=no [default]
    + --trace-pthread=yes +

    Enable/disable tracing of pthread-related events.


    • +

    +

  • --trace-symtab=no [default]
    --trace-symtab=yes

    Enable/disable tracing of symbol table reading.


    • @@ -715,7 +644,7 @@ qpngio.cpp, and so on.

    Valgrind tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and -also where the block was free'd at.. Likewise, if it should turn out +also where the block was free'd at. Likewise, if it should turn out to be just off the end of a malloc'd block, a common result of off-by-one-errors in array subscripting, you'll be informed of this fact, and also where the block was malloc'd. @@ -1057,8 +986,92 @@ shell script "valgrind". On line 4, set the environment variable installation into. + +

    2.9  The Client Request mechanism

    + +Valgrind has a trapdoor mechanism via which the client program can +pass all manner of requests and queries to Valgrind. Internally, this +is used extensively to make malloc, free, signals, etc, work, although +you don't see that. +

    +For your convenience, a subset of these so-called client requests is +provided to allow you to tell Valgrind facts about the behaviour of +your program, and conversely to make queries. In particular, your +program can tell Valgrind about changes in memory range permissions +that Valgrind would not otherwise know about, and so allows clients to +get Valgrind to do arbitrary custom checks. +

    +Clients need to include the header file valgrind.h to +make this work. The macros therein have the magical property that +they generate code in-line which Valgrind can spot. However, the code +does nothing when not run on Valgrind, so you are not forced to run +your program on Valgrind just because you use the macros in this file. +

    +A brief description of the available macros: +

      +
    • VALGRIND_MAKE_NOACCESS, + VALGRIND_MAKE_WRITABLE and + VALGRIND_MAKE_READABLE. These mark address + ranges as completely inaccessible, accessible but containing + undefined data, and accessible and containing defined data, + respectively. Subsequent errors may have their faulting + addresses described in terms of these blocks. Returns a + "block handle". Returns zero when not run on Valgrind. +

      +

    • VALGRIND_DISCARD: At some point you may want + Valgrind to stop reporting errors in terms of the blocks + defined by the previous three macros. To do this, the above + macros return a small-integer "block handle". You can pass + this block handle to VALGRIND_DISCARD. After + doing so, Valgrind will no longer be able to relate + addressing errors to the user-defined block associated with + the handle. The permissions settings associated with the + handle remain in place; this just affects how errors are + reported, not whether they are reported. Returns 1 for an + invalid handle and 0 for a valid handle (although passing + invalid handles is harmless). Always returns 0 when not run + on Valgrind. +

      +

    • VALGRIND_CHECK_NOACCESS, + VALGRIND_CHECK_WRITABLE and + VALGRIND_CHECK_READABLE: check immediately + whether or not the given address range has the relevant + property, and if not, print an error message. Also, for the + convenience of the client, returns zero if the relevant + property holds; otherwise, the returned value is the address + of the first byte for which the property is not true. + Always returns 0 when not run on Valgrind. +

      +

    • VALGRIND_CHECK_NOACCESS: a quick and easy way + to find out whether Valgrind thinks a particular variable + (lvalue, to be precise) is addressible and defined. Prints + an error message if not. Returns no value. +

      +

    • VALGRIND_MAKE_NOACCESS_STACK: a highly + experimental feature. Similarly to + VALGRIND_MAKE_NOACCESS, this marks an address + range as inaccessible, so that subsequent accesses to an + address in the range gives an error. However, this macro + does not return a block handle. Instead, all annotations + created like this are reviewed at each client + ret (subroutine return) instruction, and those + which now define an address range block the client's stack + pointer register (%esp) are automatically + deleted. +

      + In other words, this macro allows the client to tell + Valgrind about red-zones on its own stack. Valgrind + automatically discards this information when the stack + retreats past such blocks. Beware: hacky and flaky, and + probably interacts badly with the new pthread support. +

    + +

    + + + -

    2.9  If you have problems

    +

    2.10  If you have problems

    Mail me (jseward@acm.org).

    See Section 4 for the known limitations of diff --git a/coregrind/valgrind.in b/coregrind/valgrind.in index 35249d9a9e..ea7d757326 100755 --- a/coregrind/valgrind.in +++ b/coregrind/valgrind.in @@ -74,8 +74,6 @@ do --instrument=no) vgopts="$vgopts $arg"; shift;; --cleanup=yes) vgopts="$vgopts $arg"; shift;; --cleanup=no) vgopts="$vgopts $arg"; shift;; - --client-perms=yes) vgopts="$vgopts $arg"; shift;; - --client-perms=no) vgopts="$vgopts $arg"; shift;; --smc-check=none) vgopts="$vgopts $arg"; shift;; --smc-check=some) vgopts="$vgopts $arg"; shift;; --smc-check=all) vgopts="$vgopts $arg"; shift;; @@ -135,7 +133,6 @@ if [ z"$argopts" = z -o z"$dousage" = z1 ]; then echo " --workaround-gcc296-bugs=no|yes self explanatory [no]" echo " --suppressions= suppress errors described in" echo " suppressions file " - echo " --client-perms=no|yes handle client VG_MAKE_* requests? [no]" echo " --check-addrVs=no|yes experimental lighterweight checking? [yes]" echo " yes == Valgrind's original behaviour" echo diff --git a/coregrind/vg_include.h b/coregrind/vg_include.h index c3a7060b91..004cda2a43 100644 --- a/coregrind/vg_include.h +++ b/coregrind/vg_include.h @@ -230,8 +230,6 @@ extern Bool VG_(clo_optimise); extern Bool VG_(clo_instrument); /* DEBUG: clean up instrumented code? default: YES */ extern Bool VG_(clo_cleanup); -/* Handle client memory-range-permissions-setting requests? default: NO */ -extern Bool VG_(clo_client_perms); /* SMC write checks? default: SOME (1,2,4 byte movs to mem) */ extern Int VG_(clo_smc_check); /* DEBUG: print system calls? default: NO */ diff --git a/coregrind/vg_main.c b/coregrind/vg_main.c index cc47c6a779..81609ffa69 100644 --- a/coregrind/vg_main.c +++ b/coregrind/vg_main.c @@ -420,7 +420,6 @@ Bool VG_(clo_single_step); Bool VG_(clo_optimise); Bool VG_(clo_instrument); Bool VG_(clo_cleanup); -Bool VG_(clo_client_perms); Int VG_(clo_smc_check); Bool VG_(clo_trace_syscalls); Bool VG_(clo_trace_signals); @@ -504,7 +503,6 @@ static void process_cmd_line_options ( void ) VG_(clo_optimise) = True; VG_(clo_instrument) = True; VG_(clo_cleanup) = True; - VG_(clo_client_perms) = True; VG_(clo_smc_check) = /* VG_CLO_SMC_SOME */ VG_CLO_SMC_NONE; VG_(clo_trace_syscalls) = False; VG_(clo_trace_signals) = False; @@ -748,11 +746,6 @@ static void process_cmd_line_options ( void ) else if (STREQ(argv[i], "--cleanup=no")) VG_(clo_cleanup) = False; - else if (STREQ(argv[i], "--client-perms=yes")) - VG_(clo_client_perms) = True; - else if (STREQ(argv[i], "--client-perms=no")) - VG_(clo_client_perms) = False; - else if (STREQ(argv[i], "--smc-check=none")) VG_(clo_smc_check) = VG_CLO_SMC_NONE; else if (STREQ(argv[i], "--smc-check=some")) @@ -825,18 +818,6 @@ static void process_cmd_line_options ( void ) bad_option("--gdb-attach=yes and --trace-children=yes"); } -#if 0 - if (VG_(clo_client_perms) && !VG_(clo_instrument)) { - VG_(message)(Vg_UserMsg, ""); - VG_(message)(Vg_UserMsg, - "--client-perms=yes requires --instrument=yes"); - bad_option("--client-perms=yes without --instrument=yes"); - } - - if (VG_(clo_client_perms)) - vg_assert(VG_(clo_instrument)); -#endif - VG_(clo_logfile_fd) = eventually_logfile_fd; if (VG_(clo_verbosity > 0)) diff --git a/coregrind/vg_to_ucode.c b/coregrind/vg_to_ucode.c index 1998c8ee32..3bc7bb016e 100644 --- a/coregrind/vg_to_ucode.c +++ b/coregrind/vg_to_ucode.c @@ -3007,8 +3007,8 @@ static Addr disInstr ( UCodeBlock* cb, Addr eip, Bool* isEnd ) if (dis) VG_(printf)("\t0x%x: ", eip); - /* Spot the client-request magic sequence, if required. */ - if (1 /*VG_(clo_client_perms)*/) { + /* Spot the client-request magic sequence. */ + { UChar* myeip = (UChar*)eip; /* Spot this: C1C01D roll $29, %eax diff --git a/docs/manual.html b/docs/manual.html index 874f7079d8..03b7ede292 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -25,6 +25,8 @@  

    Valgrind, snapshot 20020324

    +
    This manual was minimally updated on 20020415
    +

    jseward@acm.org
    @@ -514,89 +516,6 @@ follows: buggy, so you may need to issue this flag if you use 3.0.4.

    -

  • --client-perms=no [default]
    - --client-perms=yes

    An experimental feature. -

    - When enabled, and when --instrument=yes (which is - the default), Valgrind honours client directives to set and - query address range permissions. This allows the client program - to tell Valgrind about changes in memory range permissions that - Valgrind would not otherwise know about, and so allows clients - to get Valgrind to do arbitrary custom checks. -

    - Clients need to include the header file valgrind.h - to make this work. The macros therein have the magical property - that they generate code in-line which Valgrind can spot. - However, the code does nothing when not run on Valgrind, so you - are not forced to run your program on Valgrind just because you - use the macros in this file. -

    - A brief description of the available macros: -

      -
    • VALGRIND_MAKE_NOACCESS, - VALGRIND_MAKE_WRITABLE and - VALGRIND_MAKE_READABLE. These mark address - ranges as completely inaccessible, accessible but containing - undefined data, and accessible and containing defined data, - respectively. Subsequent errors may have their faulting - addresses described in terms of these blocks. Returns a - "block handle". -

      -

    • VALGRIND_DISCARD: At some point you may want - Valgrind to stop reporting errors in terms of the blocks - defined by the previous three macros. To do this, the above - macros return a small-integer "block handle". You can pass - this block handle to VALGRIND_DISCARD. After - doing so, Valgrind will no longer be able to relate - addressing errors to the user-defined block associated with - the handle. The permissions settings associated with the - handle remain in place; this just affects how errors are - reported, not whether they are reported. Returns 1 for an - invalid handle and 0 for a valid handle (although passing - invalid handles is harmless). -

      -

    • VALGRIND_CHECK_NOACCESS, - VALGRIND_CHECK_WRITABLE and - VALGRIND_CHECK_READABLE: check immediately - whether or not the given address range has the relevant - property, and if not, print an error message. Also, for the - convenience of the client, returns zero if the relevant - property holds; otherwise, the returned value is the address - of the first byte for which the property is not true. -

      -

    • VALGRIND_CHECK_NOACCESS: a quick and easy way - to find out whether Valgrind thinks a particular variable - (lvalue, to be precise) is addressible and defined. Prints - an error message if not. Returns no value. -

      -

    • VALGRIND_MAKE_NOACCESS_STACK: a highly - experimental feature. Similarly to - VALGRIND_MAKE_NOACCESS, this marks an address - range as inaccessible, so that subsequent accesses to an - address in the range gives an error. However, this macro - does not return a block handle. Instead, all annotations - created like this are reviewed at each client - ret (subroutine return) instruction, and those - which now define an address range block the client's stack - pointer register (%esp) are automatically - deleted. -

      - In other words, this macro allows the client to tell - Valgrind about red-zones on its own stack. Valgrind - automatically discards this information when the stack - retreats past such blocks. Beware: hacky and flaky. -

    -
    • -

    - As of 17 March 02 (the time of writing this), there is a small - problem with all of these macros, which is that I haven't - figured out how to make them produce sensible (always-succeeds) - return values when the client is run on the real CPU or on - Valgrind without --client-perms=yes. So if you - write client code which depends on the return values, be aware - that it may misbehave when not run with full Valgrindification. - If you always ignore the return values you should always be - safe. I plan to fix this. There are also some options for debugging Valgrind itself. You @@ -642,6 +561,16 @@ shouldn't need to use them in the normal run of things. Nevertheless:

    Enable/disable tracing of signal handling.

    +

  • --trace-sched=no [default]
    + --trace-sched=yes +

    Enable/disable tracing of thread scheduling events.


    • +

    + +

  • --trace-pthread=no [default]
    + --trace-pthread=yes +

    Enable/disable tracing of pthread-related events.


    • +

    +

  • --trace-symtab=no [default]
    --trace-symtab=yes

    Enable/disable tracing of symbol table reading.


    • @@ -715,7 +644,7 @@ qpngio.cpp, and so on.

    Valgrind tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and -also where the block was free'd at.. Likewise, if it should turn out +also where the block was free'd at. Likewise, if it should turn out to be just off the end of a malloc'd block, a common result of off-by-one-errors in array subscripting, you'll be informed of this fact, and also where the block was malloc'd. @@ -1057,8 +986,92 @@ shell script "valgrind". On line 4, set the environment variable installation into. + +

    2.9  The Client Request mechanism

    + +Valgrind has a trapdoor mechanism via which the client program can +pass all manner of requests and queries to Valgrind. Internally, this +is used extensively to make malloc, free, signals, etc, work, although +you don't see that. +

    +For your convenience, a subset of these so-called client requests is +provided to allow you to tell Valgrind facts about the behaviour of +your program, and conversely to make queries. In particular, your +program can tell Valgrind about changes in memory range permissions +that Valgrind would not otherwise know about, and so allows clients to +get Valgrind to do arbitrary custom checks. +

    +Clients need to include the header file valgrind.h to +make this work. The macros therein have the magical property that +they generate code in-line which Valgrind can spot. However, the code +does nothing when not run on Valgrind, so you are not forced to run +your program on Valgrind just because you use the macros in this file. +

    +A brief description of the available macros: +

      +
    • VALGRIND_MAKE_NOACCESS, + VALGRIND_MAKE_WRITABLE and + VALGRIND_MAKE_READABLE. These mark address + ranges as completely inaccessible, accessible but containing + undefined data, and accessible and containing defined data, + respectively. Subsequent errors may have their faulting + addresses described in terms of these blocks. Returns a + "block handle". Returns zero when not run on Valgrind. +

      +

    • VALGRIND_DISCARD: At some point you may want + Valgrind to stop reporting errors in terms of the blocks + defined by the previous three macros. To do this, the above + macros return a small-integer "block handle". You can pass + this block handle to VALGRIND_DISCARD. After + doing so, Valgrind will no longer be able to relate + addressing errors to the user-defined block associated with + the handle. The permissions settings associated with the + handle remain in place; this just affects how errors are + reported, not whether they are reported. Returns 1 for an + invalid handle and 0 for a valid handle (although passing + invalid handles is harmless). Always returns 0 when not run + on Valgrind. +

      +

    • VALGRIND_CHECK_NOACCESS, + VALGRIND_CHECK_WRITABLE and + VALGRIND_CHECK_READABLE: check immediately + whether or not the given address range has the relevant + property, and if not, print an error message. Also, for the + convenience of the client, returns zero if the relevant + property holds; otherwise, the returned value is the address + of the first byte for which the property is not true. + Always returns 0 when not run on Valgrind. +

      +

    • VALGRIND_CHECK_NOACCESS: a quick and easy way + to find out whether Valgrind thinks a particular variable + (lvalue, to be precise) is addressible and defined. Prints + an error message if not. Returns no value. +

      +

    • VALGRIND_MAKE_NOACCESS_STACK: a highly + experimental feature. Similarly to + VALGRIND_MAKE_NOACCESS, this marks an address + range as inaccessible, so that subsequent accesses to an + address in the range gives an error. However, this macro + does not return a block handle. Instead, all annotations + created like this are reviewed at each client + ret (subroutine return) instruction, and those + which now define an address range block the client's stack + pointer register (%esp) are automatically + deleted. +

      + In other words, this macro allows the client to tell + Valgrind about red-zones on its own stack. Valgrind + automatically discards this information when the stack + retreats past such blocks. Beware: hacky and flaky, and + probably interacts badly with the new pthread support. +

    + +

    + + + -

    2.9  If you have problems

    +

    2.10  If you have problems

    Mail me (jseward@acm.org).

    See Section 4 for the known limitations of diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html index 874f7079d8..03b7ede292 100644 --- a/memcheck/docs/manual.html +++ b/memcheck/docs/manual.html @@ -25,6 +25,8 @@  

    Valgrind, snapshot 20020324

    +
    This manual was minimally updated on 20020415
    +

    jseward@acm.org
    @@ -514,89 +516,6 @@ follows: buggy, so you may need to issue this flag if you use 3.0.4.

    -

  • --client-perms=no [default]
    - --client-perms=yes

    An experimental feature. -

    - When enabled, and when --instrument=yes (which is - the default), Valgrind honours client directives to set and - query address range permissions. This allows the client program - to tell Valgrind about changes in memory range permissions that - Valgrind would not otherwise know about, and so allows clients - to get Valgrind to do arbitrary custom checks. -

    - Clients need to include the header file valgrind.h - to make this work. The macros therein have the magical property - that they generate code in-line which Valgrind can spot. - However, the code does nothing when not run on Valgrind, so you - are not forced to run your program on Valgrind just because you - use the macros in this file. -

    - A brief description of the available macros: -

      -
    • VALGRIND_MAKE_NOACCESS, - VALGRIND_MAKE_WRITABLE and - VALGRIND_MAKE_READABLE. These mark address - ranges as completely inaccessible, accessible but containing - undefined data, and accessible and containing defined data, - respectively. Subsequent errors may have their faulting - addresses described in terms of these blocks. Returns a - "block handle". -

      -

    • VALGRIND_DISCARD: At some point you may want - Valgrind to stop reporting errors in terms of the blocks - defined by the previous three macros. To do this, the above - macros return a small-integer "block handle". You can pass - this block handle to VALGRIND_DISCARD. After - doing so, Valgrind will no longer be able to relate - addressing errors to the user-defined block associated with - the handle. The permissions settings associated with the - handle remain in place; this just affects how errors are - reported, not whether they are reported. Returns 1 for an - invalid handle and 0 for a valid handle (although passing - invalid handles is harmless). -

      -

    • VALGRIND_CHECK_NOACCESS, - VALGRIND_CHECK_WRITABLE and - VALGRIND_CHECK_READABLE: check immediately - whether or not the given address range has the relevant - property, and if not, print an error message. Also, for the - convenience of the client, returns zero if the relevant - property holds; otherwise, the returned value is the address - of the first byte for which the property is not true. -

      -

    • VALGRIND_CHECK_NOACCESS: a quick and easy way - to find out whether Valgrind thinks a particular variable - (lvalue, to be precise) is addressible and defined. Prints - an error message if not. Returns no value. -

      -

    • VALGRIND_MAKE_NOACCESS_STACK: a highly - experimental feature. Similarly to - VALGRIND_MAKE_NOACCESS, this marks an address - range as inaccessible, so that subsequent accesses to an - address in the range gives an error. However, this macro - does not return a block handle. Instead, all annotations - created like this are reviewed at each client - ret (subroutine return) instruction, and those - which now define an address range block the client's stack - pointer register (%esp) are automatically - deleted. -

      - In other words, this macro allows the client to tell - Valgrind about red-zones on its own stack. Valgrind - automatically discards this information when the stack - retreats past such blocks. Beware: hacky and flaky. -

    -
    • -

    - As of 17 March 02 (the time of writing this), there is a small - problem with all of these macros, which is that I haven't - figured out how to make them produce sensible (always-succeeds) - return values when the client is run on the real CPU or on - Valgrind without --client-perms=yes. So if you - write client code which depends on the return values, be aware - that it may misbehave when not run with full Valgrindification. - If you always ignore the return values you should always be - safe. I plan to fix this. There are also some options for debugging Valgrind itself. You @@ -642,6 +561,16 @@ shouldn't need to use them in the normal run of things. Nevertheless:

    Enable/disable tracing of signal handling.

    +

  • --trace-sched=no [default]
    + --trace-sched=yes +

    Enable/disable tracing of thread scheduling events.


    • +

    + +

  • --trace-pthread=no [default]
    + --trace-pthread=yes +

    Enable/disable tracing of pthread-related events.


    • +

    +

  • --trace-symtab=no [default]
    --trace-symtab=yes

    Enable/disable tracing of symbol table reading.


    • @@ -715,7 +644,7 @@ qpngio.cpp, and so on.

    Valgrind tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and -also where the block was free'd at.. Likewise, if it should turn out +also where the block was free'd at. Likewise, if it should turn out to be just off the end of a malloc'd block, a common result of off-by-one-errors in array subscripting, you'll be informed of this fact, and also where the block was malloc'd. @@ -1057,8 +986,92 @@ shell script "valgrind". On line 4, set the environment variable installation into. + +

    2.9  The Client Request mechanism

    + +Valgrind has a trapdoor mechanism via which the client program can +pass all manner of requests and queries to Valgrind. Internally, this +is used extensively to make malloc, free, signals, etc, work, although +you don't see that. +

    +For your convenience, a subset of these so-called client requests is +provided to allow you to tell Valgrind facts about the behaviour of +your program, and conversely to make queries. In particular, your +program can tell Valgrind about changes in memory range permissions +that Valgrind would not otherwise know about, and so allows clients to +get Valgrind to do arbitrary custom checks. +

    +Clients need to include the header file valgrind.h to +make this work. The macros therein have the magical property that +they generate code in-line which Valgrind can spot. However, the code +does nothing when not run on Valgrind, so you are not forced to run +your program on Valgrind just because you use the macros in this file. +

    +A brief description of the available macros: +

      +
    • VALGRIND_MAKE_NOACCESS, + VALGRIND_MAKE_WRITABLE and + VALGRIND_MAKE_READABLE. These mark address + ranges as completely inaccessible, accessible but containing + undefined data, and accessible and containing defined data, + respectively. Subsequent errors may have their faulting + addresses described in terms of these blocks. Returns a + "block handle". Returns zero when not run on Valgrind. +

      +

    • VALGRIND_DISCARD: At some point you may want + Valgrind to stop reporting errors in terms of the blocks + defined by the previous three macros. To do this, the above + macros return a small-integer "block handle". You can pass + this block handle to VALGRIND_DISCARD. After + doing so, Valgrind will no longer be able to relate + addressing errors to the user-defined block associated with + the handle. The permissions settings associated with the + handle remain in place; this just affects how errors are + reported, not whether they are reported. Returns 1 for an + invalid handle and 0 for a valid handle (although passing + invalid handles is harmless). Always returns 0 when not run + on Valgrind. +

      +

    • VALGRIND_CHECK_NOACCESS, + VALGRIND_CHECK_WRITABLE and + VALGRIND_CHECK_READABLE: check immediately + whether or not the given address range has the relevant + property, and if not, print an error message. Also, for the + convenience of the client, returns zero if the relevant + property holds; otherwise, the returned value is the address + of the first byte for which the property is not true. + Always returns 0 when not run on Valgrind. +

      +

    • VALGRIND_CHECK_NOACCESS: a quick and easy way + to find out whether Valgrind thinks a particular variable + (lvalue, to be precise) is addressible and defined. Prints + an error message if not. Returns no value. +

      +

    • VALGRIND_MAKE_NOACCESS_STACK: a highly + experimental feature. Similarly to + VALGRIND_MAKE_NOACCESS, this marks an address + range as inaccessible, so that subsequent accesses to an + address in the range gives an error. However, this macro + does not return a block handle. Instead, all annotations + created like this are reviewed at each client + ret (subroutine return) instruction, and those + which now define an address range block the client's stack + pointer register (%esp) are automatically + deleted. +

      + In other words, this macro allows the client to tell + Valgrind about red-zones on its own stack. Valgrind + automatically discards this information when the stack + retreats past such blocks. Beware: hacky and flaky, and + probably interacts badly with the new pthread support. +

    + +

    + + + -

    2.9  If you have problems

    +

    2.10  If you have problems

    Mail me (jseward@acm.org).

    See Section 4 for the known limitations of diff --git a/valgrind.in b/valgrind.in index 35249d9a9e..ea7d757326 100755 --- a/valgrind.in +++ b/valgrind.in @@ -74,8 +74,6 @@ do --instrument=no) vgopts="$vgopts $arg"; shift;; --cleanup=yes) vgopts="$vgopts $arg"; shift;; --cleanup=no) vgopts="$vgopts $arg"; shift;; - --client-perms=yes) vgopts="$vgopts $arg"; shift;; - --client-perms=no) vgopts="$vgopts $arg"; shift;; --smc-check=none) vgopts="$vgopts $arg"; shift;; --smc-check=some) vgopts="$vgopts $arg"; shift;; --smc-check=all) vgopts="$vgopts $arg"; shift;; @@ -135,7 +133,6 @@ if [ z"$argopts" = z -o z"$dousage" = z1 ]; then echo " --workaround-gcc296-bugs=no|yes self explanatory [no]" echo " --suppressions= suppress errors described in" echo " suppressions file " - echo " --client-perms=no|yes handle client VG_MAKE_* requests? [no]" echo " --check-addrVs=no|yes experimental lighterweight checking? [yes]" echo " yes == Valgrind's original behaviour" echo diff --git a/vg_clientperms.c b/vg_clientperms.c index 15f3a3d2ad..c8d5f73190 100644 --- a/vg_clientperms.c +++ b/vg_clientperms.c @@ -263,7 +263,9 @@ Bool VG_(client_perm_maybe_describe)( Addr a, AddrInfo* ai ) if (vg_cgbs[i].kind == CG_NotInUse) continue; if (vg_cgbs[i].start - VG_AR_CLIENT_REDZONE_SZB <= a - && a < vg_cgbs[i].start + vg_cgbs[i].size + VG_AR_CLIENT_REDZONE_SZB) { + && a < vg_cgbs[i].start + + vg_cgbs[i].size + + VG_AR_CLIENT_REDZONE_SZB) { ai->akind = UserG; ai->blksize = vg_cgbs[i].size; ai->rwoffset = (Int)(a) - (Int)(vg_cgbs[i].start); @@ -278,10 +280,10 @@ Bool VG_(client_perm_maybe_describe)( Addr a, AddrInfo* ai ) void VG_(delete_client_stack_blocks_following_ESP_change) ( void ) { Addr newESP; - if (!VG_(clo_client_perms)) return; newESP = VG_(baseBlock)[VGOFF_(m_esp)]; - while (vg_csb_used > 0 && - vg_csbs[vg_csb_used-1].start + vg_csbs[vg_csb_used-1].size <= newESP) { + while (vg_csb_used > 0 + && vg_csbs[vg_csb_used-1].start + vg_csbs[vg_csb_used-1].size + <= newESP) { vg_csb_used--; vg_csb_discards++; if (VG_(clo_verbosity) > 2) @@ -303,11 +305,10 @@ UInt VG_(handle_client_request) ( ThreadState* tst, UInt* arg_block ) VG_(printf)("client request: code %d, addr %p, len %d\n", arg[0], (void*)arg[1], arg[2] ); - vg_assert(VG_(clo_client_perms)); - vg_assert(VG_(clo_instrument)); - switch (arg[0]) { case VG_USERREQ__MAKE_NOACCESS: /* make no access */ + if (!VG_(clo_instrument)) + return 0; i = vg_alloc_client_block(); /* VG_(printf)("allocated %d %p\n", i, vg_cgbs); */ vg_cgbs[i].kind = CG_NoAccess; @@ -318,6 +319,8 @@ UInt VG_(handle_client_request) ( ThreadState* tst, UInt* arg_block ) VGM_(make_noaccess) ( arg[1], arg[2] ); return i; case VG_USERREQ__MAKE_WRITABLE: /* make writable */ + if (!VG_(clo_instrument)) + return 0; i = vg_alloc_client_block(); vg_cgbs[i].kind = CG_Writable; vg_cgbs[i].start = arg[1]; @@ -327,6 +330,8 @@ UInt VG_(handle_client_request) ( ThreadState* tst, UInt* arg_block ) VGM_(make_writable) ( arg[1], arg[2] ); return i; case VG_USERREQ__MAKE_READABLE: /* make readable */ + if (!VG_(clo_instrument)) + return 0; i = vg_alloc_client_block(); vg_cgbs[i].kind = CG_Readable; vg_cgbs[i].start = arg[1]; @@ -337,17 +342,23 @@ UInt VG_(handle_client_request) ( ThreadState* tst, UInt* arg_block ) return i; case VG_USERREQ__CHECK_WRITABLE: /* check writable */ + if (!VG_(clo_instrument)) + return 0; ok = VGM_(check_writable) ( arg[1], arg[2], &bad_addr ); if (!ok) VG_(record_user_err) ( tst, bad_addr, True ); return ok ? (UInt)NULL : bad_addr; case VG_USERREQ__CHECK_READABLE: /* check readable */ + if (!VG_(clo_instrument)) + return 0; ok = VGM_(check_readable) ( arg[1], arg[2], &bad_addr ); if (!ok) VG_(record_user_err) ( tst, bad_addr, False ); return ok ? (UInt)NULL : bad_addr; case VG_USERREQ__DISCARD: /* discard */ + if (!VG_(clo_instrument)) + return 0; if (vg_cgbs == NULL || arg[2] >= vg_cgb_used || vg_cgbs[arg[2]].kind == CG_NotInUse) return 1; @@ -357,6 +368,8 @@ UInt VG_(handle_client_request) ( ThreadState* tst, UInt* arg_block ) return 0; case VG_USERREQ__MAKE_NOACCESS_STACK: /* make noaccess stack block */ + if (!VG_(clo_instrument)) + return 0; vg_add_client_stack_block ( tst, arg[1], arg[2] ); return 0; @@ -364,6 +377,8 @@ UInt VG_(handle_client_request) ( ThreadState* tst, UInt* arg_block ) return 1; case VG_USERREQ__DO_LEAK_CHECK: + if (!VG_(clo_instrument)) + return 0; VG_(detect_memory_leaks)(); return 0; /* return value is meaningless */ diff --git a/vg_include.h b/vg_include.h index c3a7060b91..004cda2a43 100644 --- a/vg_include.h +++ b/vg_include.h @@ -230,8 +230,6 @@ extern Bool VG_(clo_optimise); extern Bool VG_(clo_instrument); /* DEBUG: clean up instrumented code? default: YES */ extern Bool VG_(clo_cleanup); -/* Handle client memory-range-permissions-setting requests? default: NO */ -extern Bool VG_(clo_client_perms); /* SMC write checks? default: SOME (1,2,4 byte movs to mem) */ extern Int VG_(clo_smc_check); /* DEBUG: print system calls? default: NO */ diff --git a/vg_main.c b/vg_main.c index cc47c6a779..81609ffa69 100644 --- a/vg_main.c +++ b/vg_main.c @@ -420,7 +420,6 @@ Bool VG_(clo_single_step); Bool VG_(clo_optimise); Bool VG_(clo_instrument); Bool VG_(clo_cleanup); -Bool VG_(clo_client_perms); Int VG_(clo_smc_check); Bool VG_(clo_trace_syscalls); Bool VG_(clo_trace_signals); @@ -504,7 +503,6 @@ static void process_cmd_line_options ( void ) VG_(clo_optimise) = True; VG_(clo_instrument) = True; VG_(clo_cleanup) = True; - VG_(clo_client_perms) = True; VG_(clo_smc_check) = /* VG_CLO_SMC_SOME */ VG_CLO_SMC_NONE; VG_(clo_trace_syscalls) = False; VG_(clo_trace_signals) = False; @@ -748,11 +746,6 @@ static void process_cmd_line_options ( void ) else if (STREQ(argv[i], "--cleanup=no")) VG_(clo_cleanup) = False; - else if (STREQ(argv[i], "--client-perms=yes")) - VG_(clo_client_perms) = True; - else if (STREQ(argv[i], "--client-perms=no")) - VG_(clo_client_perms) = False; - else if (STREQ(argv[i], "--smc-check=none")) VG_(clo_smc_check) = VG_CLO_SMC_NONE; else if (STREQ(argv[i], "--smc-check=some")) @@ -825,18 +818,6 @@ static void process_cmd_line_options ( void ) bad_option("--gdb-attach=yes and --trace-children=yes"); } -#if 0 - if (VG_(clo_client_perms) && !VG_(clo_instrument)) { - VG_(message)(Vg_UserMsg, ""); - VG_(message)(Vg_UserMsg, - "--client-perms=yes requires --instrument=yes"); - bad_option("--client-perms=yes without --instrument=yes"); - } - - if (VG_(clo_client_perms)) - vg_assert(VG_(clo_instrument)); -#endif - VG_(clo_logfile_fd) = eventually_logfile_fd; if (VG_(clo_verbosity > 0)) diff --git a/vg_to_ucode.c b/vg_to_ucode.c index 1998c8ee32..3bc7bb016e 100644 --- a/vg_to_ucode.c +++ b/vg_to_ucode.c @@ -3007,8 +3007,8 @@ static Addr disInstr ( UCodeBlock* cb, Addr eip, Bool* isEnd ) if (dis) VG_(printf)("\t0x%x: ", eip); - /* Spot the client-request magic sequence, if required. */ - if (1 /*VG_(clo_client_perms)*/) { + /* Spot the client-request magic sequence. */ + { UChar* myeip = (UChar*)eip; /* Spot this: C1C01D roll $29, %eax