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: [Bug uprobes/9826] gdb/uprobes deathmatch goes to OT


On Fri, 2009-02-06 at 22:14 +0000, mhiramat at redhat dot com wrote:
> ------- Additional Comments From mhiramat at redhat dot com  2009-02-06 22:14 -------
> Can gdb use uprobe for probing target process?
> I think if the kernel supports a 'standard' method of setup break point, gdb
> doesn't need to tweak target code manually.
> 

[I'm replying outside bugzilla, since topic is much broader than the
subject of #9826.]

Certainly there's a shared vision of a user-space-breakpoint service
that could be used by kernel-side services like uprobes and by a
system-call API like ptrace or its successor.  A key feature of this
service would be to support probing of multithreaded apps with no probe
misses, as provided by uprobes and kprobes.

The ubp API I proposed here
https://www.redhat.com/archives/utrace-devel/2008-November/msg00020.h
is a first stab at such a service.  I actually coded up an x86
implementation of it -- and sent a copy to roland, cmoller, and some
Bangalore IBMers Nov. 21 -- but I never got around to testing it.  (I'll
forward you a copy, Masami.)

Roland later suggested that we factor instruction analysis out of ubp,
and also expand ubp to accommodate architectures that don't do
single-stepping per se.

As for building a system-call API atop the current uprobes... I don't
know of any support for pursuing that.

Jim




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