Capture backtrace at abort with gdb

Capture backtrace at abort with gdb

[Tom de Vries]

Hi,

I ran into a gdb abort in test-case gdb.base/bp-cmds-continue-ctrl-c.exp.

I decided to use gdb itself to try and capture the backtrace at the
point of abort.

I tried moving gdb to gdb.exec and adding a script gdb with:
...
#!/bin/sh

gdb=/path/to/gdb.exec

exec $gdb -batch -ex r -ex bt -ex q --args $gdb "$@"
...

This didn't work.  There's a difference how gdb handles ^C
normally, in which case just "Quit" is printed:
...
$ /usr/bin/gdb -q
(gdb) Quit
(gdb)
...
and when gdb is run as inferior of gdb:
...
$ /usr/bin/gdb -q -batch -ex r --args /usr/bin/gdb -q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 24707]
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff58ae6a4 in __GI___poll (fds=0x5555564d03a0, nfds=4,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
...

I managed to make this work in the end by adding this as first command:
...
-ex "handle SIGINT nostop print pass"
...

[ FWIW, the abort was the PyOS_InterruptOccurred problem for python 3.8,
fixed by commit c47bae859a "Fix Python3.9 related runtime problems". ]

I wonder:
- should we have a comment about this in testsuite/README
- should we facilitate this in some way, by having a contrib script or
  a command line switch
- should we use this mechanism in the gdb testsuite
- should we make gdb abort in a more intelligent fashion
?

Thanks,
- Tom