This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tapset difficulties w/ functions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]