Re: proposed instruction trace support in SystemTap

[Maynard Johnson <maynardj at us dot ibm dot com>]

Frank Ch. Eigler wrote:

> Dave Nomura <dcnltc@us.ibm.com> writes:
[snip]
> > > Is this sort of thing done/doable in kernel space also, or just on
> > > user-space threads?  Is there an existing kernel API for management of
> > > these registers/fields?
>
>
> > [...] There is basically one single instruction trap handler that
> > the stap translator will generate with logic to figure out what
> > handler code to run [...]
>
>
> The "existing kernel API" is the key issue here.  How exactly does one
> activate single-stepping traps on each of the interesting
> architectures, and on multiple different kernel generations (RHEL)?
> How does one hook into the handling system correctly (avoiding
> interference to other consumers of trap data like gdb, uprobes)?
I responded to some of these questions in my previous reply.  As for 
avoiding interference with other consumers of trap data, this is not 
handled in the current implementation and is TBD for the SystemTap 
proposal.  We'll investigate how other tools are handling this.  As for 
kernel debuggers, that's a pretty murky picture.  AFAIK, there isn't a 
common kernel debugger that's in mainline.  PPC64 has xmon -- don't know 
about other arch's.  We'll take a look at uprobes source to see how it 
handles this issue, but I'm not sure where to get source from.  Is it at 
http://sourceware.org/systemtap/kprobes/index.html?
> These questions need answers in order for systemtap to generate code
> to implement this.
>
>
>
> > One issue that Jim Keniston identified is that we would want some
> > way to not trace any of the nstructions in the kernel code
> > associated with stap probes, trap handler, etc.  [...]
>
>
> It's a complicated area with potential to easily bring a system down.
So true.  ;-)
> Let's stay away from it until we get some more experience with
> user-space.
I think that's a good idea.  I don't see a problem in phasing in the 
kernel tracing functionality in a later version.

Regards,
-Maynard
> - FChE