Re: Getting user-space stack backtraces in more probe contexts

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> [...]
> So, you'd proceed with user-only unwinding as I described.  When you
> come across a need for a register value and that register's state is
> "undefined", then you pause to go off and do kernel-side unwinding
> from your base probe state back to a user-mode state.  [...]

Right; this would require representation of known/unknown state in the
unwinder code, which is a new smop.  That's what I meant as opposed to
"first" below.

> 
> > > 2. Turtles all the way down!
> [...]
> > I like it.  This seems like the best first try.
> 
> Well, I'm not sure what you mean by "first".  This is little work on
> the stap/runtime side and almost entirely just a big dependency on the
> kernel compilation details being what you need.  [...]

OK, I didn't realize that the status quo was that broken.


> [...]
> > I don't like it as much.  It's far more complex, 
> 
> Agreed on complexity.  OTOH, it is in a larger sense a complexity
> reducer when one takes advantage of it to abandon prepacking CFI from
> userland binaries and instead do dynamic user CFI unwinding (just as
> userland does).

I don't see a strong connection between the unwind-data-preload vs.
two-phase unwinding.  We could attempt to access user .eh_frame data
from our current context too.  We could also attempt to page that stuff
in ahead of time (with the proviso that the kernel could throw it back
out again).


> > plus I would like not
> > to sacrifice the ability to process backtraces as first class run-time
> > objects.
> 
> I don't quite understand this.  Making backtraces a special type is
> what I'd call a "first-class" object, contrary to the status quo.  I
> suspect you mean "... process backtraces as normal run-time strings".

Yes.


> > > 4. Pre-collect via syscall-entry tracing
> > > [...]
> > 
> > I like this, but doesn't appear to handle the interrupt / signal /
> > preemption type involuntary jumps into kernel space.
> 
> I'm sorry I was not clear.  I referred to "non-system-call entries" or
> "other entries" when talking about different kinds of kernel entry,
> and these include all those kinds you mention.  You get complete
> information for these and can use 'struct pt_regs' or user_regset
> freely.

OK, I guess we'd then have to be able to know when we're in one of
these 'complete information' probe contexts.

- FChE