This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RFC: stack trace info for interpreter frames
- From: Andrew Haley <aph at cambridge dot redhat dot com>
- To: tromey at redhat dot com
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>
- Date: Thu, 29 Aug 2002 12:55:24 +0100 (BST)
- Subject: RFC: stack trace info for interpreter frames
- References: <87lm6qburq.fsf@fleche.redhat.com>
Tom Tromey writes:
> This patch changes libgcj so that it prints info about the interpreted
> function when an interpreted frame is found in a stack trace.
>
> It works by keeping a chain of stack-allocated objects describing the
> interpreted frames. Then for any frame found to be in the interpreter
> we use this information to find the actual underlying method and print
> it instead of `_Jv_InterpMethod::run'.
>
> At this point I'm asking for opinions on a few topics. The code isn't
> quite ready to go in (for one thing it doesn't handle the case where
> there is no interpreter).
>
> * Should I add a parallel array for the stack trace instead of what is
> done now (allocating one array twice as long and then using the
The double-length array is kinda kludgey.
> * Should the interpreter method info chain be kept somewhere other
> than Thread? (I chose Thread since it is already conveniently
> per-thread.)
Thread is good, and surely better than some special structure.
> * Is the technique of putting dummy functions before and after the
> interpreter function portable enough? It works ok for me on my
> Linux box, but that's hardly definitive. (If not this approach,
> then what?)
You could just look at the name of the method on the stack, but I like
the dummy functions solution well enough.
> * Anything else anyone cares to critique.
It would be nice to have a small comment explaining the
constructor/destructor trick. "Indicate that we're the top-most
interpreter frame." doesn't quite explain it all.
Andrew.