This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: FW: Java vs. Dwarf2 EH Unwinder
- From: Andrew Haley <aph at cambridge dot redhat dot com>
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: davidm at hpl dot hp dot com, rth at redhat dot com, java at gcc dot gnu dot org,gcc at gcc dot gnu dot org, hans_boehm at hp dot com
- Date: Fri, 29 Mar 2002 09:36:58 +0000 (GMT)
- Subject: Re: FW: Java vs. Dwarf2 EH Unwinder
- References: <40700B4C02ABD5119F000090278766443BF139@hplex1.hpl.hp.com><15523.53375.714774.671071@napali.hpl.hp.com><3CA3E9A6.7060100@waitaki.otago.ac.nz>
Bryce McKinlay writes:
> >
> >
> > Andrew> Surely you'd need to pass the entire processor state to the
> > Andrew> _Unwind_RaiseException() variant.
> >
> > Rich> Indeed. I would be willing to create a variant that took a
> > Rich> sigcontext* or something.
>
> That would be really good.
Surely this would require a macro very much like
MD_FALLBACK_FRAME_STATE_FOR for each target, so it wouldn't
necessarily be less porting effort. However, it would be better than
what we have at the moment because we wouldn't need to recognize the
magic sigreturn frame and we wouldn't need to unwind through glibc
frames.
> >For example, ia64 linux only saves the scratch registers on signal
> >delivery. Thus, some preserved registers may live on the signal stack
> >and you can't just short-circuit out of the signal handler.
> >
>
> OK, but it sounds like ia64 is something of a special case for
> unwinding, and it doesn't have any problem with unwinding signal frames?
I don't know enough about other operating systems to say what they do.
Surely there's no reason why a kernel must stash callee-saved
registers in the sigcontext.
> The motivation here is to get other platforms which use the dwarf2
> unwinder working for Java - the ones that are working already can
> continue to use their existing mechanism if it makes sense.
Right.
Andrew.