Tapset difficulties w/ functions

Tapset difficulties w/ functions

[Stone, Joshua I]

Hi all,

In working on the 'process' tapset, I've encountered a few difficulties
that I thought I would share, so we can search the collective mind for
solutions.  I've split this into two emails to separate the related
parts...

For the process.exec probe, the best function I found is do_execve.
However, I also need to cover compat_do_execve for the case where a
32-bit app execs on a 64-bit kernel.  The compat variant is only present
on 64-bit kernels where support for running 32-bit apps is enabled.  I
could make the inclusion of compat dependent on detecting a 64-bit
architecture, as long as no one disables 32-bit support.  Another option
is to use a wildcard match, "*do_execve", and this will work great as
long as the kernel never adds a new function that matches
(prepare_to_do_execve, perhaps).

A very clean solution I came up with requires tapset wildcards that
ignore "missing" matches.  We've discussed this before to make
"syscall.*" easier, but that was decided against.  However, here's
another example of how this could make things very clean:

  probe process.exec = _process.exec.* { /* do stuff */ }
  probe _process.exec.part1 = kernel.function("do_execve") {}
  probe _process.exec.part2 = kernel.function("compat_do_execve") {}

When the compat is missing, this would just continue silently with only
do_execve.

Another problem I have is with a signal handling probe - handle_signal
seems perfect for this, except that on the 2096_FC5 kernel this function
is inlined.  It's not decorated 'inline', so apparantly the compiler
just chose it for inlining.  On RHEL4 it is not inlined.  Without
special-casing every kernel version in a macro, I don't see a way to
detect this.  One solution is to have a new dwarf-probe that will match
both normal functions and inlines.  I also want to show that tapset
wildcards could solve this:

  probe process.signal.handle = _process.signal.handle.* { /* do stuff
*/ }
  probe _process.signal.handle.part1 = kernel.function("handle_signal")
{}
  probe _process.signal.handle.part2 = kernel.inline("handle_signal") {}

A similar mechanism could also be used to find functions that may have
been compiled as a module by switching the parts on kernel.[...] and
module("foo").[...]


Josh

Re: Tapset difficulties w/ functions

[Frank Ch. Eigler]

joshua.i.stone wrote:

> [...]
> A very clean solution I came up with requires tapset wildcards that
> ignore "missing" matches.  We've discussed this before to make
> "syscall.*" easier, but that was decided against.  However, here's
> another example of how this could make things very clean:
> 
>   probe process.exec = _process.exec.* { /* do stuff */ }
>   probe _process.exec.part1 = kernel.function("do_execve") {}
>   probe _process.exec.part2 = kernel.function("compat_do_execve") {}
> [...]

Thank you (and Martin) for keeping on this.  Such data is just what
the argument needs to move forward.

> [...] Another problem I have is with a signal handling probe -
> handle_signal seems perfect for this, except that on the 2096_FC5
> kernel this function is inlined.  [...]  One solution is to have a
> new dwarf-probe that will match both normal functions and inlines.

This was being discussed in old bug #1570.  We didn't get that to a
conclusion.  (The .inline() vs .function() distinction was invented
for supporting .function("*),.function("*").return idioms.

Would this "fault-tolerant" wildcarding have an advantage over an
explicit "optional probe" syntax like this:

probe FOO ? { } 
probe alias = BAR ?, BAZ ? { }

Then the first alternative would be expressed thusly, if they can
share handlers:

probe process.exec = kernel.function("do_execve") ?,
                     kernel.function("compat_do_execve") ?
{ /* do stuff */ }


- FChE

RE: Tapset difficulties w/ functions

[Stone, Joshua I]

On Sunday, April 30, 2006 1:05 PM, fche@redhat.com wrote:
> Would this "fault-tolerant" wildcarding have an advantage over an
> explicit "optional probe" syntax like this:
> 
> probe FOO ? { }
> probe alias = BAR ?, BAZ ? { }
> 
> Then the first alternative would be expressed thusly, if they can
> share handlers:
> 
> probe process.exec = kernel.function("do_execve") ?,
>                      kernel.function("compat_do_execve") ?
> { /* do stuff */ }

Actually, I like this explicitly-optional syntax better -- it would let
me specify in this case that do_execve is required but compat_do_execve
is optional.  In this way it is better than the "soft" wildcards.

One strong point of the wildcard is that it does ensure that there's at
least one match.  The "optional" flag can be made to do this even better
if we're careful how it's implemented.  Looking at your example, if FOO
isn't found then that probe can be discarded.  For your alias example, I
think it should work two ways if both BAR and BAZ are not found:

  probe alias {} // error, probepoint not found
  probe alias ? {} // ok, probe is discarded

Similarly, if a syscall "sys_foobar" isn't found:

tapset:
  probe syscall.foobar = kernel.function("sys_foobar") ? {}

user script:
  probe syscall.* {} // ok if other syscalls were found
  probe syscall.foobar {} // error, probepoint not found
  probe syscall.foobar ? {} // ok, probe is discarded

It still would be nice to have some syntactic sugar for
function-or-inline and kernel-or-module, lest we end up with tapsets
littered like so:

  probe xyzzy.foo = kernel.function("xyzzy_foo") ?,
                    kernel.inline("xyzzy_foo") ?,
                    module("xyzzy").function("xyzzy_foo") ?,
                    module("xyzzy").inline("xyzzy_foo") ?
  { /* do stuff */ }

Perhaps instead:

  probe xyzzy.foo = softmodule("xyzzy").softfunction("xyzzy_foo")
  { /* do stuff */ }


Josh