Jim Keniston wrote: > Ananth, Srikar, and I have been kicking this around for a few days. > With Roland rumored to be back and Chris talking about adding breakpoint > support to froggy, we figure that now's a good time to post this for > your consideration. Comments welcome. > > By the way, there are many references to single-stepping out of line > (SSOL), which is used by kprobes and uprobes. Section 6.1 of > ols.108.redhat.com/2007/Reprints/keniston-Reprint.pdf provides an > explanation of SSOL. > > Jim Keniston > > User-space Breakpoint Support (ubp) > =================================== > > Here is a plan for factoring out a portion of uprobes so that it can > be used by multiple clients -- e.g., froggy, ptrace++, or some new > layer of utrace. This subsystem encapsulates the architecture-specific > components of uprobes (excluding uretprobes): > - instruction validation and analysis > - breakpoint insertion/removal > - post-single-step cleanup > > Requirements: > ------------- > - Support probing of multithreaded apps using single-stepping out of > line (SSOL). > - Support single-stepping inline as a fallback (for architectures > with no SSOL support yet; for instructions where SSOL is tough; for > clients that can't provide an unending supply of SSOL slots). > - Be configurable as a kernel subsystem or kernel module. > > Non-requirements: > ----------------- > - Client, not ubp, creates and tracks breakpoint/probepoint objects. > In particular, ubp doesn't remember anything about ubp objects -- > including their addresses -- between calls into the ubp API. > - Client, not ubp, creates and tracks per-task objects. > - Client, not ubp, creates and manages SSOL slots. > - utrace tie-ins. The client is responsible for creating utrace > engines, quiescing threads, and handling SIGTRAP events, as needed. > - If multiple ubp clients operate simultaneously, it's up to them to > coordinate their efforts. E.g., if Client A has set a breakpoint > at address X in process Y, ubp will reject Client B's subsequent > request to do the same (since there's already a breakpoint there). > [But see enhancement request #1.] >
Just off hand, I'm fairly sure froggy will support all the
"non-requirements." It already keeps per-client (I'm not sure what you
mean by client--in froggyworld, a client is a userspace thing like gdb)
and per-attached-process information in the froggy module and thus could
keep the various objects and "SSOL slots" (whatever they are--I'll read
that pdf, I promise) and already does the utrace attach/quiesce/whatever
stuff. And since all froggy clients use the same froggy module,
coordinating multiple ubp operations should be possible.
Any chance there's some actual working ubp code I could tinker with?
Chris
> Stretch (?) Requirement:
> ------------------------
> - Support independent operation of different clients probing different
> processes. Detect and prevent collisions.
>
> Enhancement Requests:
> ---------------------
> Review has yielded the following enhancement requests:
>
> 1. Provide an API that enables different clients to place probes at
> the same virtual address in the same process. (But what other
> shared-among-clients resources would need to be managed? SSOL slots,
> at least.)
>
> Issues:
> -------
> - SSOL vma wants to be allocated by probed process. This could
> complicate a ubp-based enhancement to ptrace.
>
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
