This is the mail archive of the 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]

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.


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