This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Update PC values for JVMTI stack tracing code


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]