Re: DTRACE_PROBE and optimization

[Josh Stone <jistone at redhat dot com>]

On 09/12/2013 08:25 AM, Martin Martin wrote:
> Hi all,
> 
> In a user space program, I'm hoping to use DTRACE_PROBE for fault
> injection like this:
> 
> bool doFault = false;
> DTRACE_PROBE1(provider, mark_name, &doFault);
> if (doFault) {
>    ... inject my fault ...
> }
> 
> If DTRACE_PROBE1() compiles to a NOOP, can I be sure the compiler
> won't think doFault is always false and optimize out the if statement?

It's a tricky question, but the direct answer is that the compiler
likely will do just as you say, assume false and optimize that out.  It
certainly does when I put your code in a simple test case.

Stripping a lot of detail, that probe essentially becomes:
  __asm__ __volatile__ ("nop" :: "nor" (&doFault));

This is a NOP with no output constraints, and the input constraint "nor"
means it can be a number, offsettable memory, or a register.  Because
there's no output, the compiler can't see any way that the value might
change, so it freely propagates the "false" constant.

There are ways we could make this work in general, especially a "memory"
clobber list, but that would have a much higher impact on code
generation for all SDT consumers.  Maybe we could make this opt-in, like
a "#define SDT_CLOBBERS_MEMORY 1" for consumers like you.

Or for your specific example, you could declare doFault volatile, which
will also solve your optimization problem.


We do have a similar bug filed already:
  https://sourceware.org/bugzilla/show_bug.cgi?id=12239
... but unfortunately there's no discussion captured.  I do remember
talking about this with Roland though, so it might be in the mailing
list archives.  IIRC he said pretty much what I mentioned above, that
only a "memory" clobber would help, but that's too costly for general
SDT applications.