Re: [PATCH 1/5] gdb: terminate upon receipt of SIGFPE

[Pedro Alves <pedro@palves.net>]

On 2021-07-03 7:14 a.m., Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> Date: Fri, 2 Jul 2021 23:51:47 +0100
>>
>>> Eli> It is indeed a bad idea to return from a fatal signal handler, but
>>> Eli> terminating the GDB process is not the only safe alternative.  Another
>>> Eli> alternative is to longjmp from the signal handler to the top-level
>>> Eli> command loop.  Wouldn't that be better?
>>>
>>> I was also wondering if this would be possible -- treat it the way that
>>> gdb treats assertion failures and try to carry on.
>>
>> Unless restricted to some small defined area of code like what we do
>> with the demangler and SIGSEGV, I don't see that recovering very well, because
>> it will skip running C++ destructors, and we tend to have RAII objects
>> on the stack all the time.
> 
> Does this mean C++ doesn't allow recovering from a fatal signal?

(Note that even in C -- if you siglongjmp and skip a bunch of manual
unwinding / restoring state in mainline code, then the program will be broken too.
If we were still using C and old C-base implementation of exceptions/cleanups, then
we'd siglongjmp up to the closest sigsetjmp, not to the top level.
Longjmping to the top level directly would likely result in a broken
GDB in a similar way.)

> Isn't there some way of converting a signal into a C++ exception, and
> then unwinding "the C++ way"?
> 

Not with standard C++.  Though as an extension, with GCC, if we build GDB
with -fnon-call-exceptions, then we can throw from trapping instructions:

 -fnon-call-exceptions
 Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support
 that does not exist everywhere. Moreover, it only allows trapping instructions to throw exceptions, i.e. memory references
 or floating  point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as SIGALRM.

I don't know how portable that is, but I think the Ada and Go frontends rely
on it, so it's probably solid.

I compared '-O2' vs '-O2 -fnon-call-exceptions' builds for code size, and
the binary grew about 3%:

 $ size gdb.O2
    text    data     bss     dec     hex filename
 9332146  918258  151232 10401636         9eb764 gdb.O2
 
 $ size gdb.O2-fnon-call-exceptions
    text    data     bss     dec     hex filename
 9628267  918882  151232 10698381         a33e8d gdb.O2-fnon-call-exceptions

For Windows I think we'd need to use SEH instead and register a translator 
with _set_se_translator, but I don't know the status of SEH support in
mingw nowadays.