Re: GCJ/minGW stacktrace

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > Be a little careful with that: gnu.gcj.runtime.StackTrace isn't a
 > > public interface, and it will almost certainly change.
 > 
 > BTW, did you know that in GCJ 3.3 a class can call the package-private
 > methods of a class in a different package? I think this is a bug
 > and I'll file a PR if it's not already there.

Weird.  Could you check in a tescase for tht, please?

 > Another OT issue: by default (i.e. without -d) gcj generates .class
 > files for a class in a package in the current directory instead of
 > the directory in which the Java source is defined 

Not under Linux it doesn't.  At least it didn't the last time I tried.

 > > Pointless.  All the information we need is in the DWARF data, and the
 > > only reason we don't do proper DWARF unwinding on some targets is that
 > > we haven't got around to it.  It's easier, and much more useful, just
 > > to finish unwinder support on those targets.  
 > > 
 > > I understand that some gcc maintainers want to drop sjlj exception
 > > support altogether, and I'm coming around to that point of view.
 > 
 > AFAICT, DW2 needs a "pure" call-stack to unwind through - during
 > unwinding if intermediate call frames were generated by methods
 > that do not have DW2 FDEs, the program aborts. A limited workaround
 > for this is the MD_FALLBACK_FRAME_STATE_FOR target macro but it's
 > difficult if there are several contexts (and not just signal handler)
 > to take care of.

Nasty.  Do you know how Visual C++ does its unwinding?  There may be
enough information to make it work.

Andrew.