[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: user-space breakpoint support




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


Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]