This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ/minGW stacktrace
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/