On Sat, 2015-11-28 at 18:42 +0100, Maurice van der Pot wrote:
> Unfortunately the removal of --db-attach seems to make things less
> convenient.
Yes, for simple examination of the error context of one single thread,
--db-attach=yes was easy.
I am not completely sure how straightforward it would be to launch
gdb+vgdb from valgrind itself (a.o. I am wondering about the interaction
for stdin between gdb and the application).
In the meantime, something like the below small shell script will help.
It should give the same user experience (or better, due to vgdb more
powerful functionality?).
#! /bin/sh
cat >./vgdb-hooks.gdb <<EOF
define hook-continue
set variable \$continued_once = 1
end
define hook-stop
if \$_thread
if \$continued_once
monitor v.info last_error
end
else
if \$continued_once
quit
end
end
end
EOF
xfce4-terminal \
-e "gdb -ex 'source ./vgdb-hooks.gdb'
-ex 'target remote | vgdb --wait=10'
-ex continue " &
valgrind --vgdb-error=0 "$@"
Some small updates might be needed, or improvements might be done:
* replace xfce4-terminal by your preferred terminal
* with valgrind 3.11 and gdb 7.10, gdb will automatically discover
the executable being debugged. The above is based on these versions.
Otherwise, you will have to scan the "$@" args to find the executable
name (i.e. first argument not being a valgrind arg) and give it to
gdb as last argument
* with the above, valgrind will always show the last error, even
if in fact the application stops due to a break or signal or ...
A valgrind monitor command 'v.info new_errors' could be done to only
show the new error(s) since last request to show errors.
* you might increase --wait=10 to give enough time to valgrind to start.
Otherwise, you could write a loop to discover the new vgdb FIFO
Philippe
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
