Re: [RFA] JVMTI Stack Tracing

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Andrew Haley wrote:
 > > David Daney writes:
 > >  > Andrew Haley wrote:
 > >  > > Kyle Galloway writes:
 > >  > >
 > >  > > 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.
 > >  > >   
 > >  > It shouldn't be too difficult though.  All the unwinder does is load up 
 > >  > a framestate structure with values taken from the current thread and run 
 > >  > its state machine. 
 > >
 > > No, it's not as easy as that.  The unwinder data is not always valid:
 > > we only emit unwinder information at places where we believe an
 > > exception might be thrown.  A thread that has been pre-empted might
 > > not have unwinder data for the current PC.
 > >   
 > I knew that.  It was just temporarily forgotten.
 > 
 > However I think that if DWARF .eh_frame data is used many target 
 > architectures will always have sufficient information to  generate a 
 > stack trace.

Maybe, although we don't generate valid unwinder data during
prologues, so we'd have to be very careful not to fall off the end of
the world.

 > Actually being able to do the unwinding and discover values for all
 > variables would be problematical.

Mmm.  That's what they want.  On the other hand, gdb seems to manage
to do it, so I guess it's possible.

Andrew.