Re: 2.6 kernel syscall changes

[fche at redhat dot com (Frank Ch. Eigler)]

hunt wrote:

> The question came up in the tapset discussion, "how much do the system
> calls change?"  Here is a very quick answer.

> Syscall between 2.6.0 and 2.6.15
> -------- i386 -----------
> ADDED [20]
> ---------- x86_64 ----------
> RENAMED [3]
> ADDED [same 20]

Thanks.  These numbers give a sense of proportion when discussing the
variability of system calls.  Since 2.6.0 was released in December
2003, two years ago, this averages to less than *one change per
month*, all added or renamed.  This amount of churn does not seem that
serious.


> [...]  Now we can define probe aliases for functions that don't
> exist in the current kernel.

It's a matter of timing the error checks.  At the present, the RHS of
alias definitions is only checked during an alias expansion.  This
could be changed to have the translator check even unused aliases.

I will clarify the HACKING guidelines to spell out that tapset files
should come with a testsuite script that provides sufficient coverage,
for example, by expanding every alias.  Then buggy tapset parts would
be found by the developer rather than the user.

> If someone requests a probe on one of those, stap correctly
> generates a compilation error.  It is only wildcards that cause a
> problem. [...]

Sure, if "an error message caused by direct reference to a
kernel.syscall.buggy_alias" is not "a problem".


> I think there also needs to be a way to explicitly request that a
> probe be set on a function, if it exists, and otherwise a warning is
> printed but the script continues.

Can someone imagine a use to "optional" probes, other than the
solitary scenario we've been discussing (trace entry/exit of
"syscalls.*", blocked by buggy alias definitions in syscalls.stp)?


> So how to efficiently deal with compiler bugs that prevent access to
> function parameters or internal variables?  Ideally a warning would
> be printed but we would still compile something with the bad
> parameter or variable set to some default, like 0 or
> "unknown". [...]

In principle, this does not seem ideal to me.  If a user script refers
to some variable for its operation, then we would be doing a
disservice giving it NULL data and pretending everything was OK.  (A
warning message does not solve the problem.  It's either irrelevant to
the user and will thus annoy her, or it's relevant but then letting
the script run will produce erroneous results.)

But the parameter access problem is real.  It would be nice to have
some solution that would be useful even with correct debuginfo.

How about this: the translator could perform an early-stage
optimization during pass 2, which removes some classes of
subexpressions that have no side-effects.  This would include
assignments to variables that are never read.  Probe aliases that copy
a slew of $target variables into local script variables would quietly
tolerate the unresolvability of just those variables that are not used
by the end-user scripts.

Or this: add a syntax like "$?var" to designate var as an optional
value - the nonexistence of which the script is prepared to quietly
accept.

- FChE