examples needed

[PBrennick]

Edgar,

I have often felt it is an assembler bug, especially because I cannot consistantly reproduce it. Another thing that I do not think has ever been successfully fixed is .IF blocks. Sometimes strange things happen and certainly, EAX has to be cautiously used in these blocks. For this reason, I tend to avoid .IF blocks although I still use them. Earlier in my career, I could not afford the debugging time and did not use them at all. Nowadays, I am cautious.

The way my mind works is that a solution or algo gels in my brain over a period of time as I think about what I want to do. Once it gels, I have a window of oppotunity to get those thoughts into typed code. Once the gel point is reached, I type at a furious pace and do not have time to fool with stuff that can be problematic. So I avoid these type of things. There are others that are not at the fore in my mind at the moment but my mind knows what they are and avoids them automatically. Because of this regimen, believe it or not, I generate code that needs very little debugging to the point that I have hardly ever used Olly.

Programming for years was how I put food on the table so I became very rigid in how I do it. There are many bugs in masm as I have discovered over the years but there is not many examples that I could give you. You probably know more of them than I do; but, I would be willing to bet any amount of money that if you were to tell me a scenario that would produce a bug in the assembler; it would be a scenario that I NEVER use.

I could not help but notice that Jeremy does not use .IF blocks in his assembler. I feer he is smart... Why invite trouble.

Paul

[PBrennick]

dave,

I have been playing because I am a determined sort of guy and I have an interesting report to make and it ALWAYS fails.

Code Select Expand


CountDlgProc PROC hWind:HWND, uMsg:DWORD, wParam:WPARAM, lParam:LPARAM
;---------------------------------------
    LOCAL   Count[9]:BYTE

    .if uMsg == WM_INITDIALOG
      Invoke  SendMessage, hWind, WM_SETICON, 1, hIcon  ; Display an icon
      lea     edi, ShowString         ; List of current cell values (in ASCII)
      lea     esi, Count              ; < -- This always works
      mov     ebx, offset Count       ; Line 5472 (always fails)
      mov     esi, offset Count       ; Line 5473 (always fails)


Produces:

Sudoku.asm(5472) : error A2098: invalid operand for OFFSET
Sudoku.asm(5473) : error A2098: invalid operand for OFFSET

Interesting? Whether or not it always pertains to LOCAL variables remains to be seen. All I know is I will stick with what ALWAYS works.
Paul

[dedndave]

that is becuase the local variable does not have a fixed location (per
se) in memory - or at least, not that the assembler can recognize

local variables are on the stack and are referenced by something like "[ebp+4]", for example
offset won't work with that one

EDIT - in fact, this is why i turn off prologue/epilogue
if i want a stack frame, i will code it the old fashioned way
i have a hard enough time keeping the stack balanced without the assembler trying to do it for me
i am old enough that the mind is not as sharp as it used to be, but i can still write a stack frame - lol

[jj2007]

local variables are on the stack and are referenced by something like "[ebp+4]", for example
offset won't work with that one

You may have stumbled over that error message "register value overwritten by INVOKE". The snippet below explains why - eax is needed for a lea of a local buffer.

Code Select Expand

include \masm32\include\masm32rt.inc

.code
AppName db "Masm32:", 0
AppMsg db "Test", 0

start: call MyProc
exit

MyProc proc
LOCAL buffer[100]:BYTE
  invoke lstrcpy, addr buffer, offset AppName

  ; error A2133:register value overwritten by INVOKE
  ; xor eax, eax
  ; invoke MessageBox, eax, offset AppMsg, addr buffer, MB_OK

  invoke MessageBox, 0, offset AppMsg, addr buffer, MB_OK

;00401030              ?  8D45 9C                     lea eax, [ebp-64] <<<<<<<<< 3 bytes
;00401033              ?  50                          push eax
;00401034              ?  68 08104000                 push 00401008
;00401039              ?  6A 00                       push 0
;0040103B              .  E8 02000000                 call <jmp.&user32.MessageBoxA>

  ret
MyProc endp
end start

Same but with LOCAL buffer[130]:BYTE

Code Select Expand

00401034              ?  6A 00                       push 0
00401036              .  8D85 7EFFFFFF               lea eax, [ebp-82]      <<<<<<<< 6 bytes


[PBrennick]

JJ,

Sure have! Something else I avoid like the plague.

Dave,

It should be an error on the first pass but by the second pass addresses are resolved and it should work IMO. Anyway, it does not matter; it don't work so I avoid it in all cases that way (i am old, also) I do not have to think about it. Conditional jumps have this pratfall, also, but the assembler just waits for the second pass, should be the same for this also, both are rsoving an address.

In the old days, I NEVER used stack frames. In fact, I dislike them and feel that people do not learn about stack maintenance because of them. I use a stack frame now because others will use my code at times. I, also used obfuscation all the time which I never do any more, for the same reason.

... and, whatever the reason, I DID produce the error.

Paul

[dedndave]

well - i use stack frames occasionally
i certainly use them for recursive routines
but - generally - a direct address to a data define is a better solution
i sometimes use frames as a quick scratch-pad, where speed is not important