gdb: print backtrace on fatal SIGSEGV

This commit adds a new maintenance feature, the ability to print
a (limited) backtrace if GDB dies due to a fatal signal.

The backtrace is produced using the backtrace and backtrace_symbols_fd
functions which are declared in the execinfo.h header, and both of
which are async signal safe.  A configure check has been added to
check for these features, if they are not available then the new code
is not compiled into GDB and the backtrace will not be printed.

The motivation for this new feature is to aid in debugging GDB in
situations where GDB has crashed at a users site, but the user is
reluctant to share core files, possibly due to concerns about what
might be in the memory image within the core file.  Such a user might
be happy to share a simple backtrace that was written to stderr.

The production of the backtrace is on by default, but can switched off
using the new commands:

  maintenance set backtrace-on-fatal-signal on|off
  maintenance show backtrace-on-fatal-signal

Right now, I have hooked this feature in to GDB's existing handling of
SIGSEGV only, but this will be extended to more signals in a later
commit.

One additional change I have made in this commit is that, when we
decide GDB should terminate due to the fatal signal, we now
raise the same fatal signal rather than raising SIGABRT.

Currently, this is only effecting our handling of SIGSEGV.  So,
previously, if GDB hit a SEGV then we would terminate GDB with a
SIGABRT.  After this commit we will terminate GDB with a SIGSEGV.

This feels like an improvement to me, we should still get a core dump,
but in many shells, the user will see a more specific message once GDB
exits, in bash for example "Segmentation fault" rather than "Aborted".

Finally then, here is an example of the output a user would see if GDB
should hit an internal SIGSEGV:

  Fatal signal: Segmentation fault
  ----- Backtrace -----
  ./gdb/gdb[0x8078e6]
  ./gdb/gdb[0x807b20]
  /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20]
  /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f]
  ./gdb/gdb[0x1540f4c]
  ./gdb/gdb[0x154034a]
  ./gdb/gdb[0x9b002d]
  ./gdb/gdb[0x9b014d]
  ./gdb/gdb[0x9b1aa6]
  ./gdb/gdb[0x9b1b0c]
  ./gdb/gdb[0x41756d]
  /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3]
  ./gdb/gdb[0x41746e]
  ---------------------
  A fatal error internal to GDB has been detected, further
  debugging is not possible.  GDB will now terminate.

  This is a bug, please report it.  For instructions, see:
  <https://www.gnu.org/software/gdb/bugs/>.

  Segmentation fault (core dumped)

It is disappointing that backtrace_symbols_fd does not actually map
the addresses back to symbols, this appears, in part, to be due to GDB
not being built with -rdynamic as the manual page for
backtrace_symbols_fd suggests, however, even when I do add -rdynamic
to the build of GDB I only see symbols for some addresses.

We could potentially look at alternative libraries to provide the
backtrace (e.g. libunwind) however, the solution presented here, which
is available as part of glibc is probably a good baseline from which
we might improve things in future.

0 files changed, 0 insertions, 0 deletions