This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: catch SIGSEGV in the demangler
>>>>> "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