This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [RFA] Update PC values for JVMTI stack tracing code
- From: Tom Tromey <tromey at redhat dot com>
- To: Kyle Galloway <kgallowa at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: 20 Apr 2007 11:03:12 -0600
- Subject: Re: [RFA] Update PC values for JVMTI stack tracing code
- References: <4623D062.8010000@redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "Kyle" == Kyle Galloway <kgallowa@redhat.com> writes:
Kyle> Since the PC values stored in _Jv_InterpFrame are only updated
Kyle> when an exception can be thrown, it is possible that the
Kyle> location value obtained when getting a stack trace can be
Kyle> incorrect. Since threads can be suspended any time through
Kyle> ThreadReference.Suspend, it is necessary that the stack tracing
Kyle> code have access to the value of the PC in the interpreter at
Kyle> all times. This patch pins the PC with a pointer in
Kyle> _Jv_InterpFrame when debugging, and provides a method to
Kyle> retrieve the PC value for use in stack tracing code. This
Kyle> corrects a problem with eclipse not updating the source line
Kyle> display properly as well.
This looks pretty good but I have a comment & a related question.
Kyle> + // If the pc is NULL, either we are not debugging, or the method has not
Kyle> + // started.
I understand the "not debugging" case but not the other case. In the
debug mode I think pc_ptr will always be non-null. And, in this case,
if *pc_ptr can be read after the frame is pushed but before the method
starts executing, then it can hold garbage. That happens because...
Kyle> + pc_t pc;
.. there is no initialization of this local. Shouldn't it be
initialized to NULL?
Tom