Re: Global constants

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

Hi, Mark -

markmc wrote:

> [...]
>     const O_CREAT = 64
>     probe kernel.function ("sys_open") {
>         if ($flags & O_CREAT) {
>             printf ("foo\n");
>         }
>     }
>     ---
> Attached is a patch which implements this. [...]

Wow, I commend that you went all the way with your idea to an
implementation.  A few observations though:

The code doesn't need the { } around the printf, and the printf
doesn't need a semicolon.  Perhaps probes consisting of a single
statement shouldn't require the outer braces either:
    probe kernel.function ("sys_open") if ($flags & O_CREAT) printf ("foo\n")

The standard syscalls tapset should define such constants, so end-user
scripts do not have to.

If the main purpose of this syntax is to compress initialization of
globals into a single line, one can do it with less effort.  The
parser could rewrite
    global var = expr
to
    global var; probe begin { var = expr }
There need be no performance concerns here, partly because the
optimizer will get rid of any such globals that are not read.  It
could similarly get rid of or merge initialization "begin" probes. 

Even with this sort of rewriting, if the right hand side of such
assignments can be an expression, not just a literal, analysis &
runtime considerations could become complicated.  Consider dependency
ordering, context setup, error checking, if for example expr is a
function call dealing with other globals.

If read-only-ness of these globals is important, then a new "const"
keyword would indeed come in handy.  (I'd promptly reuse it as a
qualifier for embedded-C functions that are declared to have no
side-effects.)  I would implement this angle by a new flag on vardecl,
enforced non-lvalueness during elaboration or translation, rather than
whole new staptree.h classes.

- FChE