This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/26208] Serious problem with unwinding through signal frames



------- Comment #10 from rth at gcc dot gnu dot org  2006-02-21 18:47 -------
(In reply to comment #8)
> This is what I have so far (libjava not done yet)

The patches so far look fine.  

> but I'm not sure a simple CIE flag isn't sufficient on all arches.

You're confounding two different problems: (1) How to unwind from a signal,
at whatever point the signal is delivered, and (2) How to recognize a given
signal within an exception handling region.

Problem 1 is we arrive at the signal handler with the PC set somewhere.  We
assume that the insn at the PC is the next insn to be executed, and that all
previous insns have already been executed.  This is as true of SIGFPE as any
other signal.

Problem 2 is that the SIGFPE may be deliviered much later than the insn that
caused the signal.  This is particularly obvious with 80387, in that it may
not be delivered until the next FP insn.  The only reason we might want to
care about this problem is if we wish to turn the signal into an exception,
and send that to a surrounding catch handler.  This is not the problem we're
trying to solve in this PR.  Frankly, I'm not too concerned about solving it
ever; it requires changes to code generation to solve properly, and I've seen
no one actually request it.  If anyone would have wanted it, I would have 
expected Java, but Java runs with all FP excptions masked.

> This is most important for libjava, as libjava is doing ugly hacks around this
> problem and thus should know if S flag will be used or not.  In i386 case we
> are fine, libjava calls sigaction syscall directly and sets SA_RESTORER, so
> sigreturn pad in libjava is used.  Alpha could use the same trick

Yep.

> MD_FALLBACK_FRAME_STATE_FOR is under GCC's control, but on ppc/ppc64 we are
> in trouble when using approx. November 2005 till now kernels (before that
> there was no vDSO on ppc{,64}).

Will these kernels refuse the sa_restorer field?  I see that ppc does 
have such a field...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]