This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ/minGW stacktrace
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!
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?
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.
Admittedly, this would give only "fuzzy" answers in the sense
that the address is likely, but not surely, to belong to the
method returned.
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.
Balderdash? or Feasible?
Sincerely Yours,
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore,
INDIA. Web: http://ranjitmathew.tripod.com/