|
From: Dan S. <dan...@gm...> - 2013-03-11 16:52:26
|
Has anyone found a way that for each valgrind hit a gdb command is issued? I need a way to print a certain amount of commands per valgrind hit on a live application (i.e. variables of interest). Dan |
|
From: Philippe W. <phi...@sk...> - 2013-03-11 21:38:16
|
On Mon, 2013-03-11 at 17:52 +0100, Dan Shelton wrote: > Has anyone found a way that for each valgrind hit a gdb command is issued? > I need a way to print a certain amount of commands per valgrind hit on > a live application (i.e. variables of interest). I guess that by valgrind hit, you mean an error reported by valgrind. One way with which you can do that is to have a gdb connected to Valgrind (use --vgdb-error=0 and follow the on-screen instructions). You can then put commands in the GDB "stop hook", using define hook-stop print this_var print other_var ... any command accepted by gdb ... including the Valgrind gdbserver monitor commands end (the commands of a hook-stop are run each time your program stops). There is one weakness with the GDB hook-stop: you cannot use a continue command in the list of commands. So, the bypass is to have a file containing a *lot* of continue command. You then source this file in GDB. So, in summary, at GDB side, you do: gdb your_program define hook-stop ... all your needed commands ... end target remote | ... (as told by valgrind) set height 0 (this is needed to avoid having gdb pausing for each page of output source a_file_containing_a_lot_of_continue_command I guess it will be possible to do the above also with --db-attach=yes and giving GDB arguments to source a file of commands. This will however be very slow as this will imply two forks and one GDB execution for each error. Philippe |
|
From: Dan S. <dan...@gm...> - 2013-03-11 22:16:34
|
On 11 March 2013 22:38, Philippe Waroquiers <phi...@sk...> wrote: > On Mon, 2013-03-11 at 17:52 +0100, Dan Shelton wrote: >> Has anyone found a way that for each valgrind hit a gdb command is issued? >> I need a way to print a certain amount of commands per valgrind hit on >> a live application (i.e. variables of interest). > I guess that by valgrind hit, you mean an error reported by valgrind. > > One way with which you can do that is to have a gdb connected > to Valgrind (use --vgdb-error=0 and follow the on-screen instructions). > > You can then put commands in the GDB "stop hook", using > > define hook-stop > print this_var > print other_var > ... any command accepted by gdb > ... including the Valgrind gdbserver monitor commands > end > > (the commands of a hook-stop are run each time your program stops). > There is one weakness with the GDB hook-stop: you cannot use > a continue command in the list of commands. > So, the bypass is to have a file containing a *lot* of > continue command. > You then source this file in GDB. > > So, in summary, at GDB side, you do: > > gdb your_program > define hook-stop > ... > all your needed commands > ... > end > target remote | ... (as told by valgrind) > set height 0 (this is needed to avoid having gdb pausing for each page of output > source a_file_containing_a_lot_of_continue_command > > I guess it will be possible to do the above also with --db-attach=yes > and giving GDB arguments to source a file of commands. This will however be very slow > as this will imply two forks and one GDB execution for each error. Ouch. Do you have a simple beginner-class example which just issues the command 'where' (I know, redundant!) for each valgrind hit? I spend the last half hour with your suggestion and think that this is well beyond my current abilities without a small example usage. Dan |
|
From: Philippe W. <phi...@sk...> - 2013-03-11 22:23:54
|
On Mon, 2013-03-11 at 23:16 +0100, Dan Shelton wrote:
> Ouch.
>
> Do you have a simple beginner-class example which just issues the
> command 'where' (I know, redundant!) for each valgrind hit? I spend
> the last half hour with your suggestion and think that this is well
> beyond my current abilities without a small example usage.
Launch your valgrind with:
valgrind --vgdb-error=0 ./memcheck/tests/overlap
# this will output some lines such as:
==4718== and then give GDB the following command
==4718== target remote | /home/philippe/valgrind/trunk_untouched/install/lib/valgrind/../../bin/vgdb --pid=4718
In another window:
cat > a_lot_of_continue <<END
c
c
c
c
c
c
c
c
c
c
END
gdb ./memcheck/tests/overlap
set height 0
target remote | /home/philippe/valgrind/trunk_untouched/install/lib/valgrind/../../bin/vgdb --pid=4718
define hook-stop
print "before where"
where
print "after where"
end
source a_lot_of_continue
this will give something like:
(gdb) source a_lot_of_continue
Program received signal SIGTRAP, Trace/breakpoint trap.
$2 = "before where"
#0 0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00dc, src=0xbefd00c8, len=21)
at mc_replace_strmem.c:883
#1 0x08048632 in main () at overlap.c:40
$3 = "after where"
0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00dc, src=0xbefd00c8, len=21)
at mc_replace_strmem.c:883
883 MEMCPY(VG_Z_LIBC_SONAME, memcpy) /* fallback case */
Program received signal SIGTRAP, Trace/breakpoint trap.
$4 = "before where"
#0 0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00c8, src=0xbefd00dc, len=21)
at mc_replace_strmem.c:883
#1 0x0804867c in main () at overlap.c:42
$5 = "after where"
0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00c8, src=0xbefd00dc, len=21)
at mc_replace_strmem.c:883
883 MEMCPY(VG_Z_LIBC_SONAME, memcpy) /* fallback case */
Program received signal SIGTRAP, Trace/breakpoint trap.
$6 = "before where"
#0 0x04008927 in _vgr20090ZU_libcZdsoZa_strncpy (dst=<optimized out>, src=<optimized out>, n=21)
....
Of course, replace the print "before", where, etc by your own commands.
Philippe
|