Kyle Galloway writes:
> Andrew Haley wrote:
> > Kyle Galloway writes:
> > > This patch implments the JVMTI methods GetStackTrace and GetFrameCount.
> > > It is fairly complicated, so it warrants some explanation.
> > >
> > > This method of tracing the java stack relies on a frame list that is
> > > created as methods are called. Is extends the interpreted frame list
> > > already used, and creates a composite stack of all interpreted and JNI
> > > methods in the stack. To get a stack trace, JVMTI runs through this
> > > composite stack counting up the frames and extracting their info.
> > > _Jv_NativeFrame class is mostly empty, but could be expanded to contain
> > > more information if desired. I have also maintained compatability with
> > > the current exception stack tracing mechanism by leaving the purely
> > > interpreted list intact. I added a second variable to Thread.java
> > > called frame (as opposed to interp_frame) which is the first frame in
> > > the composite list.
> > >
> > > This method, however, has some limitations, most notably CNI. Since CNI
> > > is not called through the VM in the way that JNI is, CNI methods will
> > > not show up in this stack trace. As I understand it, however, this is
> > > not a problem since CNI cannot be used when running interpreted, but I
> > > may be wrong on this point.
> > >
> > > I have included a test case for the jvmti-interp.exp file I added
> > > yesterday, which shows GetStackTrace in action.
> > >
> > > What does everyone think? I am very open to suggestions, but given the
> > > nature of CNI and our current goals of interpreted only debugging this
> > > seems like a reasonable solution.
> >
> > I'm baffled. We already have a good way to generate stacktraces. Why
> > can't you do something like this?
> >
> >
> > _Jv_StackTrace *st = _Jv_StackTrace::GetStackTrace ();
> >
> > // If start_depth is negative use this to determine at what depth to start
> > // the trace by adding it to the length of the call stack. This allows the
> > // use of the same frame "discarding" mechanism as for a positive start_depth
> > if (start_depth < 0)
> > start_depth = *frame_count + start_depth;
> >
> > // Now check to see if the array supplied by the agent is large enough to
> > // hold frame_count frames, after adjustment for start_depth.
> > if ((*frame_count) > max_frames)
> > (*frame_count) = max_frames;
> >
> > for (int i = start_depth; i < (*frame_count); i++)
> > {
> >
> > _Jv_StackTrace::FillInFrameInfo (st[i]);
> > frames[i].method = st[i]->meth;
> >
> > // Set the location in the frame, native frames have location = -1
> > if (st[i]->type == frame_interpreter)
> > {
> > _Jv_InterpMethod *imeth
> > = static_cast<_Jv_InterpMethod *> (frame->interp->meth);
> >
> The problem with this method is that, to my knowledge, this gets a trace
> from the context in which it is called.
Aha! That makes sense, thanks. You didn't say that, so I was very
confused.
As far as I know, you're right. There doesn't seem to be any way to
use gcc's unwinder machinery to trace the stack of anything othe than
the current thread.
Approved.
Andrew.