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: documentation for user-space usage?


On Mon, 2010-11-01 at 20:53 +0000, Grant Edwards wrote:
> On 2010-11-01, Frank Ch. Eigler <fche@redhat.com> wrote:
...
> >
> > Another option is to go ahead and try to port uprobes, leave
> > ARM/utrace to us / fedora people.  When/if the newer lkml-track
> > uprobes gets merged, the hypothetical ARM port could go into the main
> > kernel that way, bypassing the utrace kerfuffle.  IOW, doing an ARM
> > port of the current systemtap-resident uprobes would not be a wasted
> > effort, if LKML gets its act together and merges the other one.
> 
> OK, thanks.  Can anybody provide a guess as to how much porting needs
> to done (assuming a competent kernel-mode programmer who knows nothing
> about the tracing stuff)?
> 

Attached is the uprobes porting guide, updated to reflect SystemTap's
version of uprobes.  Most of the functions and macros you'd need to
provide are very simple, assuming you know about how ARM's "breakpoint"
instruction works.  You can get most of this info from the kprobes code.

It looks like the ARM version of kprobes emulates instructions rather
than single-stepping them.  So the bulk of your work will be:
a) deciding which instructions you'll allow users to probe; and
b) making the emulation code (which was presumably written for kernel
instructions) work for user-space instructions.

Aside from (a) and (b) above, the uprobes port should be pretty much
paint-by-numbers coding, and then (once the utrace port gets done)
testing and debugging.

Jim Keniston

Attachment: port_stap_uprobes.txt
Description: Text document


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