Systemtap preprocessor and short-circuit boolean evaluation

Systemtap preprocessor and short-circuit boolean evaluation

[Andrew Stitcher]

I have a systemtap script (which is investigating pthread mutex
behaviour) that wants to select whether to hook probes into
pthread_mutex_lock() or the futex syscall using a command line argument.

The effect I want to achieve is only if there is a command line argument
and only if it is set to "futex" should we do the futex probe otherwise
default into pthread_mutex_lock().

What Id like to be able to write is:

%( $# >= 1 && @1 == "futex" %?
probe syscall.futex.return
...
%:
probe
process("/lib64/libpthread.so.0").function("pthread_mutex_lock").return
...
%)

However because && is not short circuiting in the preprocessor I have to
write (because if there is no first argument the boolean expression
raises an error on @1)

%( $# >= 1 %?
%( @1 == "futex"
%?
probe syscall.futex.return
...
%:
probe
process("/lib64/libpthread.so.0").function("pthread_mutex_lock").return
...
%)
%:
probe
process("/lib64/libpthread.so.0").function("pthread_mutex_lock").return
...
%)

This repetition offends me! and could be a maintenance issue in the
script going forward. Have I missed some way to avoid the repetition?

Is the idea of short circuiting boolean operators bad in the context of
the systemtap preprocessor in some way which explains why it is not
implemented that way? Is there any chance it might get implemented?

Another way of fixing my problem would be to have @n return "" if the
argument is not present but I must say I don't especially like that
idea, although it is consistent with the behaviour of systemtap arrays.

[Using systemtap 1.6-1 on Fedora 16]

Thanks

Andrew

Re: Systemtap preprocessor and short-circuit boolean evaluation

[Frank Ch. Eigler]

Andrew Stitcher <astitcher@redhat.com> writes:

> [...]
> What I'd like to be able to write is:
> %( $# >= 1 && @1 == "futex" %?
> [...]
> However because && is not short circuiting in the preprocessor I have to
> write [far more than any decent, patriotic human being should ever be
> required to; even more than the penance little six-year-old Johnny
> had to perform after teasing the neighbour's cat; oh dear, oh dear]

Yeah, that's a bug: filed as http://sourceware.org/PR13655.  It
shouldn't be too hard to fix actually.  It might just need an extra
statement or two on line 588ish.

- FChE

Re: Systemtap preprocessor and short-circuit boolean evaluation

[Andrew Stitcher]

On Thu, 2012-02-02 at 11:18 -0500, Frank Ch. Eigler wrote:
> Andrew Stitcher <astitcher@redhat.com> writes:
> 
> > [...]
> > What I'd like to be able to write is:
> > %( $# >= 1 && @1 == "futex" %?
> > [...]
> > However because && is not short circuiting in the preprocessor I have to
> > write [far more than any decent, patriotic human being should ever be
> > required to; even more than the penance little six-year-old Johnny
> > had to perform after teasing the neighbour's cat; oh dear, oh dear]
> 
> Yeah, that's a bug: filed as http://sourceware.org/PR13655.  It
> shouldn't be too hard to fix actually.  It might just need an extra
> statement or two on line 588ish.

Right - in today's master branch at line 590, but remember you still
need to skip all the tokens until the %? somehow - and the obvious
solution (just skip them) doesn't validate the syntax of what's been
skipped. Thus making any parse error messages potentially depend on the
command line.

Andrew

Re: Systemtap preprocessor and short-circuit boolean evaluation

[Frank Ch. Eigler]

Hi -

On Thu, Feb 02, 2012 at 05:04:13PM -0500, Andrew Stitcher wrote:
> [...] Thus making any parse error messages potentially depend on the
> command line.

Yup, that'd be the price to pay.  Perhaps a finer tuned try / catch
parse-error might be useful to absorb only @* errors?

- FChE