Re: architecture paper draft

[William Cohen <wcohen at redhat dot com>]

Martin Hunt wrote:
[...]

> I have something very similar.  However, I don't see a way in your
> language to specify probe locations within a function.  For example,

The grammar just posted assumed function entries.

> /* set a probe on function entry */
> probe kernel.sys_write:entry { statements }
>
> /* set a probe on function exit */
> probe kernel.sys_write:exit { statements }
>
> /* set a probe on a location define elsewhere (provider?) */
> /* "my_location" could be a line number or address */
> probe kernel.sys_write:my_location { statements }
>
> --
>
> I was also thinking of supporting something like
>
> set my_func_list {
> 	kernel.sys_write:entry
> 	kernel.sys_open:entry
> 	kernel.sys_read:entry
> }
>
> probe my_func_list { statements }

Is there an advantage to splitting my_func_list from the probe body? Are 
there cases where my_func_list would be used more than once in the 
instrumentation? Also wouldn't it make sense to factor out the ":entry"? 
It seems unlikely that it would be mixing and matching function entry 
and function exit probes.

Things might be a bit tricky in implementation. The schemes of 
implementing the probe on function probe exit have involved having an 
implicit probe on the function entry to set things up for the function 
exit. Either the multiple probe actions (explicit and implicit) will 
need to be combined into one probe or kprobes will need to allow 
multiple probes at a particular probe point.

Maybe something like the following grammar.

function_list
	: "function" "(" name_list ")" function_boundary
	;

function_boundary
    : /* empty */ /* assume entry */
    | "." "entry"
    | "." "exit"
    ;

-Will