This is the mail archive of the systemtap@sources.redhat.com 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: [PATCH 2.6.12-rc1-mm3] [1/2] kprobes += function-return


> > > int register_returnprobe(struct rprobe *rp) {
> > ...
> > 
> > > independent of kprobe and jprobe.
> > ...
> > > 
> > > make unregister exitprobes independent of kprobe/jprobe.
> > > 
> > ...
> > 
> > 1. When you call register_j/kprobe(), if kprobe->rp is non-null, it is
> > assumed to point to a retprobe that will be registered and unregistered
> > along with the kprobe.  (But this may make trouble for existing kprobes
> > applications that didn't need to initialize the (nonexistent) rp
> > pointer.  Probably not a huge deal.)
> 
> I suppose if pairing of entry and return probes is important for a user,
> he/she can always do the following:
> 
> static int ready;	// 1 = everybody registered
> 			// 2 = everybody knows we're registered
> ...
> 	ready = 0;
> 	... register_kprobe(&kp)...
> 	... register_retprobe(&rp) ...
> 	/* instant XXX -- see below*/
> 	ready = 1;
> 
> and in kp.pre_handler do
> 	if (!ready) {
> 		// return probe not registered yet
> 		return 0;
> 	}
> 	ready = 2;
> 	<body of handler>
> 
> and in rp.handler do
> 	if (ready != 2) {
> 		// Probed function entered during instant XXX,
> 		// so kp.pre_handler didn't act on it.
> 		return 0;
> 	}
> 	<body of handler>
> 
> Keeping a whole group of kprobes, jprobes, and retprobes in the starting
> gate pending a "ready" signal (e.g., for SystemTap) could probably be
> handled similarly.
> 
> Unregistration shouldn't be an issue.  At any time you can have N active
> instances of the probed function, and have therefore recorded E entries
> and E-N returns.  Hien's code handles all that on retprobe
> deregistration, but the user's instrumentation should never count on #
> probed entries == # probed returns.
> 

Jim,

You can do something like you explained above to handle the pairing issues.
You need to provide simple and compact interfaces for return probe feature.

Thanks
Prasanna
-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>


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