kernel API for in-kernel single stepping

[Dave Nomura <dcnltc at us dot ibm dot com>]

Paul,
  It looks like you have vast experience with single stepping in the 
kernel (sstep.[hc]).  In a previous mail you mentioned that there is 
only a "scouts honor" convention with use of the kernel's single step 
trapping mechanism that is followed by the kernel debuggers with only 
one client at a time using the resources.   With the various kernel 
debuggers, kprobes, itrace, and maybe others trying to share these 
resources do you think it is time to develop some sort of kernel single 
stepping API?   Frank is requesting this  API  before  changing  
SystemTap to support  single step traps.

I'm not an experienced kernel developer so this is way beyond my 
expertise.  Is this something you would consider tackling?
Roland?  Can you suggest anyone else?

If this is not feasible/advisable then we'd like to know so that we can 
move forward on the instruction tracing support in SystemTap.

Dave

Frank Ch. Eigler wrote:
> Dave Nomura <dcnltc@us.ibm.com> writes:
>
>   
> > It appears that ptrace() wouldn't be able to deliver acceptable
> > performance for instruction tracing.  Do you think that utrace would
> > be a reasonable alternative?
> >     
>
> That's what Roland is saying.  The next question is "who shall
> prototype a single-stepping-on-top-of-utrace kernel module?".  With
> such a prototype in hand, plopping support into systemtap is a small
> step beyond.
>
> - FChE

Roland McGrath (roland@redhat.com) writes:
> For user-mode stepping (all you can do via ptrace), this is what the utrace
> in-kernel APIs give you.  The in-kernel case has enough different issues
> that I think it's appropriate to consider it an entirely separate case.
> For that, kprobes already has its fingers in this area of machine-specific
> code.  It might make most sense for in-kernel stepping to be an extension
> of the kprobes code.  OTOH, with the hw_breakpoint (nee kwatch) work by
> Alan Stern <stern@rowland.harvard.edu> we have a second in-kernel case that
> (on some machines) wants to get involved with single-stepping.  Perhaps it
> makes sense to consolidate the efforts on some shared low-level part that
> deals with the stepping part.  Or there may not be enough to be done there
> that anything beyond current machine-specific calls and trap notifiers are
> really required.  (Off hand I think at least some kind of coordination will
> be required to avoid these three things stepping on each other's toes.)
>
>
> Thanks,
> Roland


--
Dave Nomura
LTC Linux Power Toolchain