This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: [KPROBE][RFC] Tweak to the function return probe design
- From: "Lynch, Rusty" <rusty dot lynch at intel dot com>
- To: "Hien Nguyen" <hien at us dot ibm dot com>
- Cc: <systemtap at sources dot redhat dot com>, <amavin at redhat dot com>, <jkenisto at us dot ibm dot com>, <prasanna at in dot ibm dot com>, "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- Date: Wed, 8 Jun 2005 12:25:35 -0700
- Subject: RE: [KPROBE][RFC] Tweak to the function return probe design
From: Hien Nguyen [mailto:hien@us.ibm.com]
>Hi Rusty,
>
>This looks good. See my comments below
>
>Rusty Lynch wrote:
>
<snip>
>>* Instead of storing the stack address in the return probe instance,
the
>> task pointer is stored. This gives us all we need in order to:
>> - find the correct return probe instance when we enter the
trampoline
>> (even if we are recursing)
>>
>>
>What about the case user probing different functions in the same task?
>As I and Jim discussed about this, it probably works since you put the
>RI the hlist and get it out in the same order. But in the case user
>probing several function-returns but the one in the middle never
return,
>your code would fire the wrong handler.
How could I not return from a function but still return from a previous
call (i.e. have the parent function return with the child function left
in limbo)? I guess you could directly mess with the instruction
pointer, but wouldn't that mess up the stack address anyway?
>
>I thought I would be safer for us to have the "statck_addr" field in
>kretprobe_instance structure for sanity check. It would not be much
>code to add, just one line to populate the stack_addr in the
>arch_prepare_kretprobe() and may be a couple line to do the check in
the
>handler.
The concept of a stack address to uniquely identify a specific call
instance inside a task is architecture dependant. I would really like
to resolve if it is possible for a function with the same task living
on.
<snip>
>>@@ -155,8 +148,8 @@ struct kretprobe_instance {
>> struct hlist_node uflist; /* either on free list or used list */
>> struct hlist_node hlist;
>> struct kretprobe *rp;
>>- void *ret_addr;
>>- void *stack_addr;
>>+ unsigned long *ret_addr;
>>
>>
>As Ananth suggested to me before, you could use
>
> kprobe_opcode_t * ret_addr;
>
Yea, I like that better.
--rusty