Re: [Valgrind-users] Removal of db-attach

[Philippe W. <phi...@sk...>]

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