Good idea.  Looks relatively straightforward:

* Import libbacktrace from gcc
* Update top-level configury so it is a dependency of gdb
* Change gdb's internal error to call into libbacktrace

Is anything else needed?  All I can think of is maybe some
test suite tweaks.

FTR, first mentioned here ( https://sourceware.org/pipermail/gdb/2020-July/048788.html ).

Patch submitted: https://sourceware.org/pipermail/gdb-patches/2021-August/181548.html

The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=91f2597bd24d171c1337a4629f8237aa47c59082

commit 91f2597bd24d171c1337a4629f8237aa47c59082
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Thu Aug 12 18:24:59 2021 +0100

    gdb: print backtrace for internal error/warning
    
    This commit builds on previous work to allow GDB to print a backtrace
    of itself when GDB encounters an internal-error or internal-warning.
    This fixes PR gdb/26377.
    
    There's not many places where we call internal_warning, and I guess in
    most cases the user would probably continue their debug session.  And
    so, in order to avoid cluttering up the output, by default, printing
    of a backtrace is off for internal-warnings.
    
    In contrast, printing of a backtrace is on by default for
    internal-errors, as I figure that in most cases hitting an
    internal-error is going to be the end of the debug session.
    
    Whether a backtrace is printed or not can be controlled with the new
    settings:
    
      maintenance set internal-error backtrace on|off
      maintenance show internal-error backtrace
    
      maintenance set internal-warning backtrace on|off
      maintenance show internal-warning backtrace
    
    Here is an example of what an internal-error now looks like with the
    backtrace included:
    
      (gdb) maintenance internal-error blah
      ../../src.dev-3/gdb/maint.c:82: internal-error: blah
      A problem internal to GDB has been detected,
      further debugging may prove unreliable.
      ----- Backtrace -----
      0x5c61ca gdb_internal_backtrace_1
            ../../src.dev-3/gdb/bt-utils.c:123
      0x5c626d _Z22gdb_internal_backtracev
            ../../src.dev-3/gdb/bt-utils.c:165
      0xe33237 internal_vproblem
            ../../src.dev-3/gdb/utils.c:393
      0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag
            ../../src.dev-3/gdb/utils.c:470
      0x1549652 _Z14internal_errorPKciS0_z
            ../../src.dev-3/gdbsupport/errors.cc:55
      0x9c7982 maintenance_internal_error
            ../../src.dev-3/gdb/maint.c:82
      0x636f57 do_simple_func
            ../../src.dev-3/gdb/cli/cli-decode.c:97
       .... snip, lots more backtrace lines ....
      ---------------------
      ../../src.dev-3/gdb/maint.c:82: internal-error: blah
      A problem internal to GDB has been detected,
      further debugging may prove unreliable.
      Quit this debugging session? (y or n) y
    
      This is a bug, please report it.  For instructions, see:
      <https://www.gnu.org/software/gdb/bugs/>.
    
      ../../src.dev-3/gdb/maint.c:82: internal-error: blah
      A problem internal to GDB has been detected,
      further debugging may prove unreliable.
      Create a core file of GDB? (y or n) n
    
    My hope is that this backtrace might make it slightly easier to
    diagnose GDB issues if all that is provided is the console output, I
    find that we frequently get reports of an assert being hit that is
    located in pretty generic code (frame.c, value.c, etc) and it is not
    always obvious how we might have arrived at the assert.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377

patch committed, marking resolved-fixed.