This is possibly related to the earlier post about problems with breakpoints in case statements.

If a breakpoint/tracepoint is set on an IF statement, the break/trace will only occur when the "if" condition is true.  Consider the code fragment

     if ( true ) {          // breakpoint set on this line
           x = 42 ;
     } // if ( true )

     if ( false ) {          // breakpoint set on this line, too
           y = 42 ;
     } // if ( false )

Identical breakpoints are set on the two source lines.  When execution passes through, the first breakpoint will fire but not the second.  Given that the condition in a typical if statement will sometimes be true and sometimes not, this is going to look like inconsistent behavior.

Well, you're missing *my* point which may or may not be a correct interpretation of the "if" construct.

In my (admittedly old fashioned) view, an "if" statement consists of two parts:  A conditional test and a body.  The outcome of the conditional test determines whether the body of the "if" gets executed.  I therefore consider the conditional test and the body to be two separate entities, and I'd like to be able to set a breakpoint on one or the other.

As for your question about "real code", the fragment I supplied was what I added to my app upon becoming suspicious about why I wasn't getting any hits.  The original code looked more like

    if ( count > 50 ) {
        call_some_function( ) ;
    }

I had the breakpoint set on the line containing the "if ( count > 50 ) {".  As long as count was less than 50, which was most of the time, the breakpoint was not firing and I spent a couple hours trying to figure out why.

Perhaps the problem is that breakpoints are set on a "line", which leaves open the question of whether an "if" statement is one line or several.  I'm an old assembler programmer so I would expect the compiler generated code for the above to look something like

    mov reg, count
    sub reg, 50
    blt label
    callsub call_some_function
label:

I thought I was putting the breakpoint on the 'instruction' at the beginning of the test, i.e. "mov reg, count", not on the call to call_some_function.

Now, another legal expression of the "if" construct is 

    if ( cond ) statement ;

or even

   if ( cond ) { statement1 ; statement2 ; ... }

In these cases, it's far less obvious whether a breakpoint set on the source code line is for the conditional test or the statement 'block'.  Moreover, it may be impossible for your debug code injector to deal with this situation in the way I would like.

Is it?

I haven't tried this in real world C, at least not recently, but I will and I'll be very much surprised if hitting a VS breakpoint set on the "if" depends on the outcome of the conditional test.  I don't accept existing C/C++/C# implementations to be a binding precedent, but they will set expectations.

Or maybe not.  As you have pointed out, MCU applications are fundamentally different than sorting mailing lists for "Teen Beat" magazine.  There are at least some, and possibly many cases in which we simply have to explain what VM/DT does and why.

Anyway, I'll try it and report back.

I agree that my problem with breakpoints on an "if" statement is a failure to consider the architectural limitations of injected code.  This issue is closed with RTFM.

I have a half-baked idea for a pre-pend option on the injected breakpoints that I'll post in a different thread.

Sorry for the confused bother.