This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: where do stack traces get filled in?
- From: Tom Tromey <tromey at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: "Boehm, Hans" <hans_boehm at hp dot com>, "'Jeff Sturm'" <jsturm at one-point dot com>, Andrew Haley <aph at redhat dot com>, Adam Megacz <gcj at lists dot megacz dot com>, java at gcc dot gnu dot org, "MOSBERGER, DAVID (HP-PaloAlto,unix3)" <davidm at hpl dot hp dot com>
- Date: 13 Dec 2001 15:39:55 -0700
- Subject: Re: where do stack traces get filled in?
- References: <40700B4C02ABD5119F000090278766443BEE2D@hplex1.hpl.hp.com> <20011213135522.E6920@redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "rth" == Richard Henderson <rth@redhat.com> writes:
>> I'm not sure whether this will be done in a 3.1 timeframe. (I'm personally
>> also a little concerned about doing this to close before a release.) But
>> David (and Richard?) should definitely be involved in any discussions along
>> these lines.
rth> It's already possible to collect backtrace data during the phase1
rth> unwind process. We're just not doing it. See my comments in
rth> __gcj_personality_v0:
rth> // FIXME: In Phase 1, record _Unwind_GetIP in xh->obj as a part of
rth> // the stack trace for this exception. This will only collect Java
rth> // frames, but perhaps that is acceptable.
One twist here is that for libgcj it isn't entirely sufficient to find
the name of the frame's method. If we're looking at an interpreter
(or, some day, JIT) frame, then we need to extract further information
from the interpreter. Perhaps that can be done by some
interpreter-specific data structure on the side though. Adding a bit
more overhead to each interpreter invocation won't be a significant
(or perhaps even noticeable) problem.
Tom