Re: catch SIGSEGV in the demangler

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> SIGSEGV being a synchronous signal, this makes it so that the
Pedro> original instruction that triggered the segv is reexecuted, and
Pedro> the SIGSEGV is raised again.  The difference is that this way our
Pedro> handler is transparent -- the segv's siginfo will be more rich,
Pedro> including a si_addr that points at the address that caused the
Pedro> fault, (si_code will still show it was a userspace generated
Pedro> signal), and "handle_segv" will not appear in the backtrace.  Did
Pedro> you try that and decided against?

I didn't try, because the C standard says this is undefined behavior:

   If and when the function returns, if the value of sig is SIGFPE,
   SIGILL, SIGSEGV, or any other implementation-defined value
   corresponding to a computational exception, the behavior is
   undefined; otherwise the program will resume execution at the point
   it was interrupted.

I couldn't find anything in POSIX suggesting otherwise.

It seems to me that the failing spot will still be in the backtrace.
So, the damage isn't so severe:

(gdb) bt
#0  0x0000003be3036540 in __sigprocmask (how=2, set=0x2f32850, oset=0x0)
    at ../sysdeps/unix/sysv/linux/ia64/sigprocmask.c:43
#1  0x0000003be303610b in __libc_siglongjmp (env=0x2f32808, val=-1)
    at longjmp.c:36
#2  0x0000003be3c0e179 in longjmp (env=<optimized out>, val=<optimized out>)
    at ../nptl/sysdeps/pthread/pt-longjmp.c:27
#3  0x0000000000722e48 in throw_exception (exception=...)
    at ../../archer/gdb/exceptions.c:234
#4  0x0000000000802a33 in handle_segv (sig=11)
    at ../../archer/gdb/safe-demangle.c:49
#5  <signal handler called>
#6  0x0000003be30e87c8 in __GI___poll (fds=0x2e2cff0, nfds=3, 
    timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83
#7  0x000000000072d1be in gdb_wait_for_event (block=1)
    at ../../archer/gdb/event-loop.c:863


Well, ok, the stack trace is weird, since in this scenario we aren't
actually calling longjmp.  I'm not sure what is going on there.

If returning actually works everywhere, I am fine with doing that.

Tom