proposed instruction trace support in SystemTap
Maynard Johnson
maynardj@us.ibm.com
Tue Jul 10 20:57:00 GMT 2007
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
More information about the Systemtap
mailing list