Unexpected Evaluate/Modify behavior
lazarus / 12-Debugger

----------------------------------------------------------------------
440bx · 2019-05-06 20:21

Hello,

The evaluate/modify window does not seem to set the variable to the
specified value.

Use the following test program and follow the steps to see the
problem:Code: Pascal  [Select][+][-]window.onload = function(){var x1
= document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i {$APPTYPE
 CONSOLE} program _BinaryAndBehavior; uses  Windows  ; procedure
DoIt;var  MenuItemState : UINT; begin  MenuItemState := 0;      {
change value using evaluate/modify               }  //MenuItemState :=
8;    { set to this value using evaluate/modify          }   if
MenuItemState and MF_CHECKED > 0 then  begin    writeln('  ** Inside
if  **');  end;end; begin  DoIt;   writeln('Press return/enter to end
this program');  readln;end.Follow these steps:

1.  uncomment line 15.  This should cause "  ** inside if **" to
print.
2.  comment back line 15
3. place a breakpoint on line 17.
4. when the breakpoint hits, use the evaluate/modify window to change
the value of MenuItemState to 8.  This should cause the writeln('  **
inside if **') to execute BUT, it does not.  Yet, even the locals
window shows that MenuItemState has the value 8.

end of post.

----------------------------------------------------------------------
Martin_fr · 2019-05-06 20:51

I did some tests:

64bit app: works (-O1 and -O0)
32bit app: works only with -O0

While O1 is "debugger friendly" (I might remove that), it is not
"debugger perfect". 

O1 runs something called the "peephole optimizer".
And that means, that a value that is already loaded into a cpu
register, is not refreshed from memory, between two statements. Yet
the debugger only knows the value that is in memory.

This also does not depend on what debugger is used.
The debug info written by fpc (stabs and dwarf) only specify that the
value is at location X in memory.

Full asm code would look like
Code: [Select]  mov 0 => eax
  move eax => mem

  move mem => eax  // peephole removes this line
  and 8, eax
  test eax for 0
 ....


Setup for the debugger:
http://wiki.lazarus.freepascal.org/Debugger_Setup

----------------------------------------------------------------------
Martin_fr · 2019-05-06 20:56

Heck, even fpc -h prints that

Code: [Select] -O<x>  Optimizations:
      -O-        Disable optimizations
      -O1        Level 1 optimizations (quick and debugger friendly)
      -O2        Level 2 optimizations (-O1 + quick optimizations)
      -O3        Level 3 optimizations (-O2 + slow optimizations)
      -O4        Level 4 optimizations (-O3 + optimizations which
might have unexpected side effects)
Well, the resulting exe may in all friendship tell the debugger the
one or other white lie....

----------------------------------------------------------------------
440bx · 2019-05-06 21:01

Quote from: Martin_fr on May 06, 2019, 10:51:23 pmI did some tests:

64bit app: works (-O1 and -O0)
32bit app: works only with -O0

While O1 is "debugger friendly" (I might remove that), it is not
"debugger perfect".

Thank you Martin.  That explains it.

Yes, I usually have O1 set (it's the default and it is supposed to be
"debugger friendly")  A friendly little white lie it turns out.

I'm somewhat surprised that the 64bit would not have the same
"peephole optimizer" problem as the 32bit version (I understand they
are different but, they are supposed to do the same job, the results
should be very similar.)

Thanks again.

----------------------------------------------------------------------
Martin_fr · 2019-05-06 21:04

Btw, "eval and modify"

You can not modify managed types. (string/array)
This will lead to crashes or undefined behaviour.

----------------------------------------------------------------------
440bx · 2019-05-06 21:22

Quote from: Martin_fr on May 06, 2019, 11:04:56 pmBtw, "eval and
modify"

You can not modify managed types. (string/array)
This will lead to crashes or undefined behaviour.
That is good to know, thank you.  One more reason not to use managed
types.