The little red dot (F9)

[WSinc]

Hello -

Sometimes I see some strange behavior when trying to set a breakpoint (F9 key).
It happens more often when the breakpoint is set in the middle of an IF-THEN-ELSE construct.

The little dot appears several lines BELOW the statement I am sitting
at when when I press F9. It appears at a place that cannot be executed, i.e. a FORMAT statement.

Sometimes it appears in a DIFFERENT routine than the one I'm in, if there are two or more routines in one file.

This behavior CAN SOMETIMES BE CORRECTED by closing down VS and reopening it.

Should it be necessary to compile the routine BEFORE setting a breakpoint? I thought the
F9 function attaches to the source file, and not the compiled code.

In other words, shouldn't I be able to set the breakpoint before compiling the code?

This is one of those situations where a REMOTE ASSIST could illustrate it, but sending the file will not.

[mecej4]

When you specify a line breakpoint, the debugger needs to map the file+line-number to an address. Often, and especially with some level of optimization on, the correlation between line-number and address can become tenuous. If you change the source code but start debugging without recompiling, it can get very "interesting".

It is not unusual to step into a subprogram and see the current line move through non-executable statements, or to see surprisingly wide jumps in the current line when executing DO loops.

[WSinc]

Perhaps, to make the debugging process less confusing, there is a way to completely
disable the optimization, at least until one is in the "production" mode.

This might explain why I sometimes am not able to put a breakpoint at the START of a do-loop.
But I don't see why optimization would play a part there.


For example:

DO I=1,10
DO J=1,10
K=I+J
END DO
END DO

Sometimes setting the breakpoint right at the FIRST do statement results in
the breakpoint being set at the THIRD statement. I just don't see how optimization would have
any bearing on this.

Can one (if necessary) display the machine code and set the breakpoint there?
At least that might "zero in" where we want to set it.

[mecej4]

> Can one (if necessary) display the machine code and set the breakpoint there?

Definitely. In fact, if the program was compiled without generating debugging symbols, Disassembly mode is the only way to debug. Depending on the version of VS you use, you may need to set a breakpoint at the start address or the _main or MAIN, ..., and reach that breakpoint before you can see the disassembly.

Here is a complete subroutine with your DO loops

[fortran]subroutine dlp integer :: i,j,k DO I=1,10 DO J=1,10 K=I+J END DO END DO end subroutine dlp [/fortran] When compiled with default optimization, it produces only one instruction:

[bash] PUBLIC _DLP _DLP PROC NEAR ret[/bash] How do we match the address of the "ret" instruction with the line numbers of the DO loops?

[Steven_L_Intel1]

Yes, you can display the assembler code. Debug > Windows > Disassembly. You can set breakpoints on individual instructions.

[jimdempseyatthecove]

With aggressive optimization it is possible for the eventual result of K can be computed at compile time. In which case the 5 lines of code can be reduced to

K = precompiled result

Additionally, if K is not used subsequent to the K= then the code can be remove completely.

I am not claiming that IVF will optimize to that extent, however, the optimizer could concievably reduce the inner loop to a single statement

K=I + (1+2+3+4+5+6+7+8+9+10)

where (1+2+3+4+5+6+7+8+9+10) is reduced at compile time toa single value (55)

Jim Dempsey

[WSinc]

Well, certainly this example can be reduced to k=55 by the compiler.

But I am taking about situations with DO consructs or
IF-THEN-ELSE constructs where
optimization is not that obvious.

That example above: How could PROC NEAR be one instruction?
There is no way to tell what is contained in it.

The DO loops would actually take the sum of 200 numbers.

[mecej4]

>That example above: How could PROC NEAR be one instruction?

The forum software hides the initial part of the line. It is, actually,

_DLP PROC NEAR

This line, however, is only an assembler directive and produces no instructions. The following line contains a RET instruction, which produces (in 32-bit mode) the single byte instruction C3.

The compiler can observe that the subroutine has no arguments, does not call other subroutines or functions, and does not modify any variables in COMMON, and therefore need not produce any object code for the executable statements in the subroutine.

However, the compiler cannot prevent a CALL to this subroutine to be made from elsewhere, so the RET instruction is needed. If inter-procedural optimization were enabled, the compiler could remove all CALLs to the subroutine from the object code, and the entire subroutine could left out of the linking process.