This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [patch 3.4/3.5] libffi & libjava port for hppa-linux
Randolph Chung writes:
> > MD_FALLBACK_FRAME_STATE_FOR has not yet been written, as far as I can
> > see. This is part of finishing the gcj port.
>
> let me piggyback here and ask a question about this :)
>
> suppose you have:
>
> try { send signal }
> catch (int x) { /* some code */ }
>
> sighandler(int sig) { throw sig; }
>
> the unwinder is supposed to start in the signal handler, read the
> signal frame (from MD_FALLBACK_FRAME_STATE_FOR) and unwind you back to
> the try-catch frame, right?
Yup. Well, sorta: MD_FALLBACK_FRAME_STATE_FOR copies saved registers
from the signal frame to _Unwind_FrameState and then sets things up so
that the _next_ time uw_frame_state_for() is called, it returns the
context of the point at which the signal was triggered.
> the comments in uw_frame_state_for() say:
>
> /* Couldn't find frame unwind info for this function. Try a
> target-specific fallback mechanism. This will necessarily
> not provide a personality routine or LSDA. */
>
> which is true... no personality routine, but then in
> _Unwind_RaiseException_Phase2(), if the unwound frame is the try/catch
> block and there is no personality routine, it will cause an abort
> ("/* Don't let us unwind past the handler context */").
Well, yes: but the unwound frame cannot both be a try/catch block and
the sigreturn frame. When you get to the try/catch block, there will
be a personality routine.
Andrew.