Re: Unsafe mode for probes

[Arkady <arkady dot miasnikov at gmail dot com>]

Frank,

"a proper context structure allocation for temporary values" is
one of the things I would like to wrap into a stable API, and
do not enforce it.

"Unsafe" means that the stack safety is up to the author.

For example, if I hook only entry points of the system calls I
want the freedom to inject custom C code.

Arkady.

On Thu, Aug 9, 2018 at 11:07 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> arkady.miasnikov wrote:
>
>> My typical probe looks like this
>>
>> probe syscall.accept4.return ?
>> {
>>     %{HIT_MAP_INC(HIT_MAP_SYSCALL_ACCEPT4_RETURN)%}
>>     send_incident_result(%{INCDENT_TYPE_SYSCALL_ACCEPT4%}, $return);
>> }
>> [...]
>
>> The actual assembler of the probe will contain quite a bit of code
>> handling local variables, call to lock, etc
>> For short probes I can shave about 20% of CPU cycles.
>
> A blanket "unsafe" probe cannot make do with no checks at all, e.g.
> a proper context structure allocation for temporary values, etc.
> It's a matter of detail - which checks particularly should one skip?
>
> It is not unlikely that some of that initialization / lock business in
> the probe prologue could be elided entirely with some more cleverness
> during translation.  Like a new pragma for embedded-C functions that
> skip the context-struct based api, which in turn could make it
> unnecessary to have a context struct at all for that probe.  Stuff
> like that - but it takes analysis to figure out which is needed
> and which is not.  stap -p3 ftw.
>
> - FChE