Using and understanding the Valgrind core: Advanced Topics
•
v.set {gdb_output | log_output | mixed_output}
allows redirection of the Valgrind output (e.g.
the errors detected by the tool). The default setting is
mixed_output
.
With
mixed_output
, the Valgrind output goes to the Valgrind log (typically stderr) while the output of the
interactive GDB monitor commands (e.g.
v.info last_error
) is displayed by GDB.
With
gdb_output
, both the Valgrind output and the interactive GDB monitor commands output are displayed by
GDB.
With
log_output
, both the Valgrind output and the interactive GDB monitor commands output go to the Valgrind
log.
•
v.wait [ms (default 0)]
instructs Valgrind gdbserver to sleep "ms" milli-seconds and then continue.
When sent from a standalone vgdb, if this is the last command, the Valgrind process will continue the execution of
the guest process. The typical usage of this is to use vgdb to send a "no-op" command to a Valgrind gdbserver so as
to continue the execution of the guest process.
•
v.kill
requests the gdbserver to kill the process. This can be used from a standalone vgdb to properly kill a
Valgrind process which is currently expecting a vgdb connection.
•
v.set vgdb-error <errornr>
dynamically changes the value of the
--vgdb-error
argument. A typical
usage of this is to start with
--vgdb-error=0
on the command line, then set a few breakpoints, set the vgdb-error
value to a huge value and continue execution.
The following Valgrind monitor commands are useful for investigating the behaviour of Valgrind or its gdbserver in
case of problems or bugs.
•
v.info gdbserver_status
shows the gdbserver status. In case of problems (e.g. of communications),
this shows the values of some relevant Valgrind gdbserver internal variables.
Note that the variables related to
breakpoints and watchpoints (e.g. the number of breakpoint addresses and the number of watchpoints) will be
zero, as GDB by default removes all watchpoints and breakpoints when execution stops, and re-inserts them when
resuming the execution of the debugged process. You can change this GDB behaviour by using the GDB command
set breakpoint always-inserted on
.
•
v.info memory [aspacemgr]
shows the statistics of Valgrind’s internal heap management.
If option
--profile-heap=yes
was given, detailed statistics will be output. With the optional argument
aspacemgr
.
the segment list maintained by valgrind address space manager will be output. Note that this list of segments is
always output on the Valgrind log.
•
v.info scheduler
shows the state and stack trace for all threads, as known by Valgrind.
This allows to
compare the stack traces produced by the Valgrind unwinder with the stack traces produced by GDB+Valgrind
gdbserver. Pay attention that GDB and Valgrind scheduler status have their own thread numbering scheme. To
make the link between the GDB thread number and the corresponding Valgrind scheduler thread number, use the
GDB command
info threads
. The output of this command shows the GDB thread number and the valgrind
’tid’. The ’tid’ is the thread number output by
v.info scheduler
. When using the callgrind tool, the callgrind
monitor command
status
outputs internal callgrind information about the stack/call graph it maintains.
•
v.set debuglog <intvalue>
sets the Valgrind debug log level to <intvalue>. This allows to dynamically
change the log level of Valgrind e.g. when a problem is detected.
44
Содержание BBV
Страница 176: ...Valgrind FAQ Release 3 8 0 10 August 2012 Copyright 2000 2012 Valgrind Developers Email valgrind valgrind org ...
Страница 177: ...Valgrind FAQ Table of Contents Valgrind Frequently Asked Questions 1 ii ...
Страница 302: ...README mips based on newer GCC versions if possible 95 ...
Страница 303: ...GNU Licenses ...
Страница 304: ...GNU Licenses Table of Contents 1 The GNU General Public License 1 2 The GNU Free Documentation License 8 ii ...