architecture paper draft
William Cohen
wcohen@redhat.com
Fri Jan 28 21:45:00 GMT 2005
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
More information about the Systemtap
mailing list