Re: [PUSHED 6/6] gdb: print backtrace for internal error/warning

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Eli Zaretskii <eliz@gnu.org> [2021-09-28 15:26:47 +0300]:

> > From: Andrew Burgess <andrew.burgess@embecosm.com>
> > Date: Tue, 28 Sep 2021 12:26:24 +0100
> > 
> >   ../../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
> > ---
> >  gdb/NEWS                                      |   8 ++
> >  gdb/doc/gdb.texinfo                           |  13 ++
> >  .../gdb.base/bt-on-error-and-warning.exp      | 118 ++++++++++++++++++
> >  gdb/testsuite/gdb.base/bt-on-fatal-signal.exp |  36 ------
> >  gdb/utils.c                                   |  36 +++++-
> >  5 files changed, 174 insertions(+), 37 deletions(-)
> >  create mode 100644 gdb/testsuite/gdb.base/bt-on-error-and-warning.exp
> > 
> > diff --git a/gdb/NEWS b/gdb/NEWS
> > index d7c29c82edb..1e25cb8cc36 100644
> > --- a/gdb/NEWS
> > +++ b/gdb/NEWS
> > @@ -19,6 +19,14 @@ show source open
> >    to open and read source code files, which can be useful if the files
> >    are located over a slow network connection.
> >  
> > +maint set internal-error backtrace on|off
> > +maint show internal-error backtrace
> > +maint set internal-warning backtrace on|off
> > +maint show internal-warning backtrace
> > +  GDB can now print a backtrace of itself when it encounters either an
> > +  internal-error, or an internal-warning.  This is on by default for
> > +  internal-error and off by default for internal-warning.
> 
> Does this depend on libbacktrace?  If so, should that be mentioned in
> the documentation?

I'm not sure.  libbacktrace is now included within the binutils-gdb
repository, so it's not like this is a dependency that users will need
to hunt down and install on their own.

It is true that libbacktrace could potentially not be supported/built
on a particular target, but then GDB falls back to the libc
backtrace() API, so libbacktrace isn't a hard requirement for getting
such a backtrace, it's just one possible requirement.

Would you suggest that this dependency situation be described in the
actual .texinfo docs?  Or just mentioned in the NEWS file?

If you can give some more guidance, I'll try to draft some suitable
words.

> 
> > +When @value{GDBN} reports an internal problem (error or warning) it is
> > +possible to have a backtrace of @value{GDBN} printed to stderr.  This
> 
> I suggest "standard error stream" instead of "stderr".

Thanks, I fixed the two places I said 'stderr' with the patch below
which I pushed.

Thanks,
Andrew

---

commit 4180173142185f0967dfefb131e4843a17779c86
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Wed Sep 29 09:25:03 2021 +0100

    gdb/doc: use 'standard error stream' instead of 'stderr' in some places
    
    With this commit:
    
      commit 91f2597bd24d171c1337a4629f8237aa47c59082
      Date:   Thu Aug 12 18:24:59 2021 +0100
    
          gdb: print backtrace for internal error/warning
    
    I included some references to 'stderr', which, it was pointed out,
    would be better written as 'standard error stream'.  See:
    
      https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html
    
    This commit replaces the two instances of 'stderr' that I introduced.

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index d4e4174be5d..c156a1d6739 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -39266,9 +39266,9 @@
 @itemx maint set internal-warning backtrace @r{[}on|off@r{]}
 @itemx maint show internal-warning backtrace
 When @value{GDBN} reports an internal problem (error or warning) it is
-possible to have a backtrace of @value{GDBN} printed to stderr.  This
-is @samp{on} by default for @code{internal-error} and @samp{off} by
-default for @code{internal-warning}.
+possible to have a backtrace of @value{GDBN} printed to the standard
+error stream.  This is @samp{on} by default for @code{internal-error}
+and @samp{off} by default for @code{internal-warning}.
 
 @kindex maint packet
 @item maint packet @var{text}
@@ -39768,9 +39768,9 @@
 @itemx maint show backtrace-on-fatal-signal
 When this setting is @code{on}, if @value{GDBN} itself terminates with
 a fatal signal (e.g.@: SIGSEGV), then a limited backtrace will be
-printed to stderr.  This backtrace can be used to help diagnose
-crashes within @value{GDBN} in situations where a user is unable to
-share a corefile with the @value{GDBN} developers.
+printed to the standard error stream.  This backtrace can be used to
+help diagnose crashes within @value{GDBN} in situations where a user
+is unable to share a corefile with the @value{GDBN} developers.
 
 If the functionality to provide this backtrace is not available for
 the platform on which GDB is running then this feature will be