Re: GCJ/minGW stacktrace

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > We have all the symbolic information we need in Java's reflection
 > > data.  However, we need to be able to convert a return address into
 > > the start adress of a method, and to do that we need to know where
 > > each method begins and ends.  That is the information in the DWARF
 > > unwinder daya.
 > 
 > Since I build (for now) GCJ/MinGW using DW2 EH, I was able
 > to use the classAt( ) and methodAt( ) methods from
 > gnu.gcj.runtime.StackTrace to get a much better backtrace
 > even from stripped executables. Nice!

Be a little careful with that: gnu.gcj.runtime.StackTrace isn't a
public interface, and it will almost certainly change.

 > So c++filt is not really needed after all.
 > 
 > However, how do you plan to get line numbers and source file
 > names without using addr2line or libbfd? Do you have something
 > in mind to remove even this dependency?

We don't always have the source file information: it's an optional
part of the Java .class file format, and it's not compulsory for stack
traces.

It's nice to have, of course.  I could add the line numbers and source
file names to the object file.  That wouldn't be very hard.  Or maybe
decode the DWARF debug info in libgcj -- harder, but not by any means
impossible.

 > More importantly, why do you need DW2 FDEs at all? You maintain
 > a map of all the method invocation addresses anyways using
 > reflection data - instead of a map, maintain a data structure
 > that can better answer "greatest value less-than-or-equal-to"
 > (assuming a linear, contiguous address space) type queries
 > and you're done. If nothing, a sorted array or a balanced
 > binary tree would do the job.

That's what I did first, but it was broken.  Firstly, I wanted to
identify a method with more confidence than a fuzzy match will allow,
especially for security purposes.  Secondly, searching a tree is
slower than simply doing a lookup in a map, and we need to do this a
lot.  Finally, we've got to have the DWARF unwinder data in order to
handle exceptions in a reasonable way, so we might as well use it.

 > If you want to be more precise, you can perhaps add another
 > field to _Jv_Method indicating the size of the generated code
 > and use this to answer the query more accurately.

I tried that too.  See
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01522.html.

 > Balderdash? or Feasible?

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.

Andrew.