This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: proposed instruction trace support in SystemTap


On Tue, Jul 10, 2007 at 03:57:39PM -0500, Maynard Johnson wrote:
> 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?

Kprobes and xmon on powerpc use the same trap variant instruction. A
scheme is in place to pass on traps that aren't caused due to kprobes.
This is done using the notifier infrastructure in kernel... see
kprobes_exceptions_notify(). If kprobes gets notified of a trap caused
due to an xmon breakpoint, it'll just retury NOTIFY_DONE indicating that
it didn't find an entry corresponding to the trap address in its table
and hence is meant for some other consumer - xmon or any other
interested tool. The notifier mechanism then invokes the next interested
party in the chain (if one is registered).

Ananth


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]