Valgrind Software, Быстрый старт

Страница: 50 / 319

Using and understanding the Valgrind core: Advanced Topics
Float shadow registers are shown by GDB as unsigned integer values instead of float values, as it is expected that these
shadow values are mostly used for memcheck validity bits.
Intel/amd64 AVX registers ymm0 to ymm15 have also their shadow registers. However, GDB presents the shadow
values using two "half" registers. For example, the half shadow registers for ymm9 are xmm9s1 (lower half for set 1),
ymm9hs1
(upper half for set 1),
xmm9s2
(lower half for set 2),
ymm9hs2
(upper half for set 2). Note the inconsistent
notation for the names of the half registers: the lower part starts with an
x
, the upper part starts with an
y
and has an
h
before the shadow postfix.
The special presentation of the AVX shadow registers is due to the fact that GDB independently retrieves the lower
and upper half of the
ymm
registers. GDB does not however know that the shadow half registers have to be shown
combined.
3.2.8. Limitations of the Valgrind gdbserver
Debugging with the Valgrind gdbserver is very similar to native debugging. Valgrind’s gdbserver implementation is
quite complete, and so provides most of the GDB debugging functionality. There are however some limitations and
peculiarities:
• Precision of "stop-at" commands.
GDB commands such as "step", "next", "stepi", breakpoints and watchpoints, will stop the execution of the process.
With the option
--vgdb=yes
, the process might not stop at the exact requested instruction. Instead, it might
continue execution of the current basic block and stop at one of the following basic blocks. This is linked to the fact
that Valgrind gdbserver has to instrument a block to allow stopping at the exact instruction requested. Currently,
re-instrumentation of the block currently being executed is not supported. So, if the action requested by GDB (e.g.
single stepping or inserting a breakpoint) implies re-instrumentation of the current block, the GDB action may not
be executed precisely.
This limitation applies when the basic block currently being executed has not yet been instrumented for debugging.
This typically happens when the gdbserver is activated due to the tool reporting an error or to a watchpoint. If the
gdbserver block has been activated following a breakpoint, or if a breakpoint has been inserted in the block before
its execution, then the block has already been instrumented for debugging.
If you use the option --vgdb=full , then GDB "stop-at" commands will be obeyed precisely. The downside
is that this requires each instruction to be instrumented with an additional call to a gdbserver helper function,
which gives considerable overhead (+500% for memcheck) compared to
--vgdb=no
. Option
--vgdb=yes
has
neglectible overhead compared to
--vgdb=no
.
• Processor registers and flags values.
When Valgrind gdbserver stops on an error, on a breakpoint or when single stepping, registers and flags val-
ues might not be always up to date due to the optimisations done by the Valgrind core.
The default value
--vex-iropt-register-updates=unwindregs-at-mem-access
ensures that the registers needed to
make a stack trace (typically PC/SP/FP) are up to date at each memory access (i.e. memory exception points).
Disabling some optimisations using the following values will increase the precision of registers and flags values (a
typical performance impact for memcheck is given for each option).
• --vex-iropt-register-updates=allregs-at-mem-access (+10%) ensures that all registers and
flags are up to date at each memory access.
• --vex-iropt-register-updates=allregs-at-each-insn (+25%) ensures that all registers and
flags are up to date at each instruction.
38