Re: catch SIGSEGV in the demangler

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre> sigaction is not available everywhere and is tested by configure
Pierre> see 	remote-sim.c:999

Pierre>  I don't know the exact status of sigaltstack function, but
Pierre> I would be surprised that it is supported on systems that
Pierre> don't support sigaction...

Yeah, thanks.

Pierre> Also, sigaction can return the previous signal handler,
Pierre> so why not use this previous handle instead of SIG_DFL?

I don't mind changing this, but it seems like if this gives a result
other than SIG_DFL, then we've done something weird.  There should be
only one handler installed.

Pierre> Would it make sense to still throw an exception even if not inside  the
Pierre> demangler?

I was thinking of perhaps expanding the scope somewhat.

One idea I had was to introduce a new RETURN_SEGV to return_reason and
*not* add this to RETURN_MASK_ALL.

Then, have a special throw_segv that first looks to see if anything
expects to catch it, and if not, reset the handler and re-raise the
signal.

This way we could let code handle SEGV when appropriate, without tying
it to the demangler -- but also without catching all SEGVs that occur in
gdb.

I think we probably want to let some SEGVs through for the benefit of
external crash-catchers like ABRT.  But, maybe not -- I've also been
wondering if a SEGV should be treated like internal_error instead.
Maybe sometimes gdb could limp on after a SEGV.

Pierre>   I was also surprised by the fact that you called the new file
Pierre> safe-demangle.c, why not simply name it gdb-demangle.c?

I didn't want to confuse it with the existing demangle.c.

Tom