RFC: stack trace generation

[Casey Marshall]

Hi,

Something I've been working on recently is finding a way to get a
decent Java stack trace, complete with file and line number
information, without using external processes (the problems with GCJ's
Process implementation notwithstanding, the current method is too
slow, and doesn't work on my target platform when a lot of the code is
in shared libraries).

I've modified gnu.gcj.runtime.NameFinder so that it does two things
differently: the first, it uses StackTrace to determine the class and
method name of each frame, instead of demangling symbols. I don't know
why the code doesn't do it this way already, since it looks to me to
be faster and more reliable; are the StackTrace methods less reliable
than I think they are?

Secondly, for code loaded from shared libraries, NameFinder looks up
the DWARF-2 debug_line section, and reads the file and line number
from that. This works, and I can get accurate debug stack traces, but
even that is slow, especially when resolving names in a large library
(like libgcj.so).

There are ways to speed this up, of course. As is, the code has to
parse the debug info for every PC in the stack, which is wildly
inefficient. A better way to do this would be to look up all addresses
in the stack at once, and to keep a running map between PC and debug
info. I think it would be possible to even allow pluggable name
resolvers, where NameFinder will try each in sequence to try to make
as complete a stack trace as possible; but even without a pluggable
architecture we could still have, at minimum, a DWARF-2 reader and
the info provided by Mark's interpreter patch.

I'd like to know what people think of this idea -- to change the
semantics of NameFinder so it looks up the stack as a whole, and
whether or not a pluggable resolver is a good idea. Since I don't want
to assume that every platform uses DWARF-2, I thought it might be good
to leave room for other methods.

I will attach what I've come up with so far, but I don't consider this
patch complete.

-- 
Casey Marshall || csm@gnu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: namefinder.patch
Type: text/x-patch
Size: 43914 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040716/d556850c/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DebugInfo.java
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040716/d556850c/attachment.ksh>