Re: [PATCH 0/2] Demangler crash handler

[Gary Benson <gbenson at redhat dot com>]

Tom Tromey wrote:
> Pedro> Then stealing a signal handler always has multi-threading
> Pedro> considerations.  E.g., gdb Python code could well spawn a
> Pedro> thread that happens to call something that wants its own
> Pedro> SIGSEGV handler...  Signal handlers are per-process, not
> Pedro> per-thread.
> 
> That is true in theory but I think it is unlikely in practice.  And,
> should it happen -- well, the onus is on folks writing extensions
> not to mess things up.  That's the nature of the beast.  And, sure,
> it is messy, particularly if we ever upstream "import gdb", but even
> so, signals are just fraught and this is not an ordinary enough
> usage to justify preventing gdb from doing it.

GDB installs handlers for INT, TERM, QUIT, HUP, FPE, WINCH, CONT,
TTOU, TRAP, ALRM and TSTP, and some other platform-specific ones
I didn't recognise.  Is there anything that means SIGSEGV should
be treated differently to all these other signals?

> The choice is really between SEGV catching and "somebody else
> down the road fixes more demangler bugs".

The demangler bugs will get fixed one way or another.  The choice is:
do we allow users to continue to use GDB while the bug they've hit is
fixed, or, do we make them wait?  In the expectation that they will
put their own work aside while they fix GDB instead?

Thanks,
Gary

-- 
http://gbenson.net/