Re: backtrace() vs. _Unwind_Backtrace()

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Andrew,

> > >DWARF EH was previously enabled for Win32, but problems occurred where 
> > >exceptions need to be thrown through OS callback frames (that don't 
> > >have unwind info), which is a common requirement for Win32 code, so it 
> > >uses SJLJ exceptions for now. So, it would need a way to unwind through 
> > >info-less OS frames so that the DWARF unwinder can resume unwinding on 
> > >the other side (ie a generalized MD_FALLBACK_FRAME_STATE_FOR).
> > 
> > I know little-to-nothing about this, but did this have to do with the structured
> > exception handler in win32.cc? If so, it looks like the two things we're trying
> > to deal with there are access violations and divides by zero. Because of the
> > issue you mentioned, -fcheck-references and -fuse-divide-subroutine were
> > later added:
> > 
> > http://gcc.gnu.org/ml/java-patches/2003-q2/msg00269.html
> > 
> > ...so is my analysis correct that because of these additions, we can now
> > revert to DWARF EH on Win32? Ranjit?

>Well, it's true that in general you no longer have to unwind through
>exception handler frames.  However, there's still a problem with
>exceptions thrown in CNI code.  I am proposing, probably post 3.4
>split, to change CNI so that null pointer checks are enabled even in
>CNI code.

>So, DWARF EH sounds like a batter plan.  Unless there's some other
>reason I don't know about...

I wasn't clear on whether you meant now or post-3.4.

(The CNI code is completely bug-free, so this shouldn't be an issue, right?)

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/