GCJ/minGW stacktrace

Ranjit Mathew rmathew@hotmail.com
Sun Jan 26 04:05:00 GMT 2003


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.

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 - this is unlike
the JDK from Sun and causes immediate problems when resolving
references to the said class.


> 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.

Because Windows GUI programs use a lot of Windows callbacks, EH
with DW2 doesn't work and that's why the MinGW maintainers have
reverted to SJLJ.

Which means that GCJ/Win32 will not be able to benefit from these
neat improvements you have been working on. :-(

Sincerely Yours,
Ranjit.

-- 
Ranjit Mathew        Email: rmathew AT hotmail DOT com
Bangalore,
INDIA.               Web: http://ranjitmathew.tripod.com/




More information about the Java mailing list