0

My assembly program is acting strange in debugging mode. I am using Visual Studio 2017 to run a loop, which I expect to break when ecx equals 0. However, in debugging mode, the loop continues decrementing ecx after it equals 0. I tried many different values for ecx and the outcome was the same. The loop works fine when I run the program without debugging. Would appreciate any tips on getting my program to work in debugging mode. 

Include Irvine32.inc

.data
edward BYTE "edward cox",0
array BYTE 0,1
dat BYTE ?
.code

main proc
    call ReadChar
    sub eax,48 ; convert char to int
    mov ecx, eax
    sub ecx, 1 ; loop will run ecx-1 times
    mov bl, 2 ; next value in fib sequence
    L1: ; continues looping after ecx = 0
        loop L1
    mov edx, OFFSET edward
    call WriteString
    call crlf
    invoke ExitProcess,0
main endp
end main
I Like
  • 1,711
  • 2
  • 27
  • 52
  • 2
    The `loop` instruction decrements before testing against zero. – Raymond Chen Apr 07 '18 at 18:09
  • Check what register size is really used in this LOOP instruction. Unfortunately, this isn't declared in mnemonics. – Netch Apr 07 '18 at 18:10
  • Which values have tried as input (the values in `EAX` after `ReadChar` returns)? – Hadi Brais Apr 07 '18 at 18:13
  • "The loop works fine when I run the program without debugging" Do you mean with optimizations enabled? Because the compiler may optimize the loop away, so there woudn't be a loop in the first place and you'd not see the problem indeed. – Hadi Brais Apr 07 '18 at 18:15
  • @HadiBrais : the code here isn'r generated from a compiler. It is straight assembly code using Irivne32 library and MASM will not remove the loop. My best guess is that he's using the debugger incorrectly. Mayne a difference between step over and step into – Michael Petch Apr 07 '18 at 18:25
  • @MichaelPetch Oh yes, an assembler wouldn't do that. That was the only explanation I could think of. We need more info from OP. – Hadi Brais Apr 07 '18 at 18:26
  • finally think i found the source of the problem. When I removed ReadChar to read a character from the console, the loop behaved normally. Not sure why this solved the problem though. Per the Irvine32lib site Read Char is defined as follows: ReadChar PROC Reads a single character from standard input and returns the character in the AL register. The character is not echoed on the screen. Waits for the character if none is currently in the input buffer.` – I Like Apr 07 '18 at 18:51
  • Since the loop body is empty, how do you know it's working when running it? – Margaret Bloom Apr 07 '18 at 20:01
  • i was checking value of register ecx – I Like Apr 07 '18 at 20:35
  • `ReadChar` retuns in `AL`, not `EAX`. You should use `movzx ecx, al` / `sub ecx, '0'`. Are you sure you weren't looking at `CL` instead of `ECX`? – Peter Cordes Apr 08 '18 at 04:18
  • Also, Margaret is asking how you know it's "working fine" outside the debugger? The loop body is empty, so an initial ecx value of `0` on loop entry would lead to at most a 10 second delay on a 2GHz CPU. But other than timing, you'd have no indication of how many iterations the loop ran. – Peter Cordes Apr 08 '18 at 04:19
  • Unless your debugger is severely broken, `ecx=0` when execution reaches `mov edx, OFFSET edward`. That's the only way `loop` can fall through. (And thus `ecx` was `1` before the last execution of `loop` ). If you're not seeing that with your debugger, it's broken or you're using it wrong. Or you assembled this as 64-bit code so it's actually decrementing `rcx`, because the default address-size is 64 in 64-bit mode. – Peter Cordes Apr 08 '18 at 04:41

0 Answers0