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]

conf call: utrace futures


Application tracing requirements/utrace exploitation
Notes from conference call 7/23/07

Feel free to correct/clarify.
Jim

Attendees:
Red Hat: Roland McGrath, Mark Wielaard, Frank Eigler
IBM: Srikar Dronamraju, Ananth Mavinakayanahalli, Jim Keniston,
	Mike Mason, Vara Prasad, Vivek Goyal, Maneesh Soni, Dave Wilder
Oracle: Kris Van Hees, Elena Zannoni

See Roland's TODO list for utrace:
http://people.redhat.com/roland/utrace/TODO

Does Roland intend that utrace eventually include user-space probing,
as currently provided by uprobes?  No, that feature won't be part of
the utrace core; it'll be a utrace client like the current uprobes
implementation.  Roland views the current uprobes as a vehicle for
identifying and addressing issues in this space.

Roland is disappointed in the rate of progress in the "refactoring"
of uprobes that he suggested.  (Need to clarify this.  Roland mentioned
instruction decoding in particular.  Is this just about analysis of the
probed instruction at probe-registration time for more efficient and/or
more platform-independent fixups at single-step time?  What other
components are involved in the "refactoring"?)

IBM has SSIL implementations working for powerpc, x86_64, and s390, and
is currently working on SSOL for those platforms.  SSOL for i386 works
as tested.

Roland views the "stop/quiesce all threads" capability as something
to be provided outside the utrace core, but available to all utrace
clients.

Roland envisions an fd-based user-level API to utrace (i.e.,
an alternative to ptrace).  Tracer process identifies event(s) of
interest in traced thread(s).  When an event occurs, a user-specified
sequence of one or more predefined handlers runs in the kernel,
after which control may optionally pass to the (polling?) tracer.
(How does this relate to the utracer work that Chris Moller is doing?)

Utrace currently uses TIF_SIGPENDING to stop/quiesce a running task.
This can cause a system call to fail with EINTR. (Ptrace has this
problem.)  "Soft quiesce" would allow the system call to complete.
This is easy to explain but hairy to implement.  Implementation will
probably wait 'til after upstream acceptance.

An "extension event" is a client-defined event that may occur in an
"unsafe" context (e.g., interrupt context, locks held, etc.), but
is reported to the utrace client at the next "safe" point (i.e.,
so the callback can lock/block as needed).

What about non-destructive application core dumps?  Roland thinks
utrace already provides everything that's needed:
1) stopping all threads -- QUIESCE mechanism
2) dumping memory (solved elsewhere)
3) thread state -- See utrace_regset().  The intention is that
	regset 0 be the standard register set (a la pt_regs),
	and regset 1 be floating point regs.

What's wrong with gcore?  Performance -- e.g., it's ptrace based.
Roland would prefer to see something integrated with utrace.

What about the problem of distinguishing SIGTRAPs from the various
sources?  Roland envisions reporting breakpoint and single-step
traps before they turn into SIGTRAPs.  Using the notifier mechanism,
a la kprobes?  Probably not, but right in that timeframe.

What's a good forum for discussing utrace?  Let's use the SystemTap
mailing list for now.

When will utrace be upstream?  Roland will try to get it back into
-mm in 2.6.23, but some of the same obstacles remain:
- Roland needs to renew efforts to get certain architecture
maintainers to port utrace.
- Still some bugs to chase down.

What about syslets?  (I missed some of this discussion because I
misheard the original question.)  "Still pie in the sky."



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