Re: [PATCH 4/5] gdb: print backtrace on fatal SIGSEGV

[Pedro Alves <pedro@palves.net>]

On 2021-07-04 3:38 p.m., Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> Cc: andrew.burgess@embecosm.com, gdb-patches@sourceware.org
>> Date: Sun, 4 Jul 2021 15:32:19 +0100
>>
>> That was the answer.  The patch does not remove the "internal error ..."
>> message, there was never any.  It does not add one either.  Before the patch, GDB
>> dumps core (w/ SIGABRT), and after patch it prints a backtrace and then
>> dumps core (w/ SIGSEGV).
> 
> Shouldn't we add the "internal error" message?  That's what those
> fatal signals are, after all, right?
> 

Can you clarify what you mean by "message"?  When we talk about that, I'm thinking
that you're talking about the whole shebang, including the querying whether to exit
and dump core, like:

(gdb) maint internal-error 
../../gdb/maint.c:91: internal-error: 
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

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

../../gdb/maint.c:91: internal-error: 
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(gdb) 


All this querying isn't async-signal-safe, we couldn't do it from the signal handler.

We can of course print something similar to just the parts without a query:

 A problem internal to GDB has been detected,
 further debugging may prove unreliable.

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

Maybe say a "fatal signal" instead of "problem internal", something like that.

The patch doesn't do that, but it does sound like a good idea to make it do it.

This is the sort of detail that made me ask for an example of what the backtrace
looks like.