Later versions of MASM - More Passes

[raleeper]

Do later versions of masm use more than two passes [or more than 6.14, which I believe just does 2]?

jj2007:  Is there a chance a later masm would avoid the bug you reported in Topic FormatMessage Error?

Thanks, robert

[later]

My reason for special interest now is that several times lately I have been debugging away when I notice the source doesn't match the dissambly, which means the last assembly failed - and I missed any error message.  For now the only thing I can do is be more careful to notice output from the assembly, and check when starting a DBG session that dissassembly matches source.

I think these occasions have all been while I was working on macros, and I think maybe the failures would not have occurred if masm used a third pass.  [So another thing I can do is avoid macros defined other than by methods I know work]

[jj2007]

jj2007:  Is there a chance a later masm would avoid the bug you reported in Topic FormatMessage Error?

No, I used the latest one. The wrong stack alignment is present up to MASM version 8.0. Version 9 and 10, and the latest JWasm version, work fine
Think about DednDave's remark that most code is a mix of decimal and hex code anyway. Adding the h to all immediate integers is not a big job, although I understand your resistance, of course.

My reason for special interest now is that several times lately I have been debugging away when I notice the source doesn't match the dissambly, which means the last assembly failed - and I missed any error message.  For now the only thing I can do is be more careful to notice output from the assembly, and check when starting a DBG session that dissassembly matches source.

I think these occasions have all been while I was working on macros, and I think maybe the failures would not have occurred if masm used a third pass.  [So another thing I can do is avoid macros defined other than by methods I know work]

A concrete example would be helpful and interesting. Out of my belly, I can see only two reasons:
1. disassembly doesn't show macros (but lst files do)
2. Olly occasionally produces garbage listings, if it starts interpreting on the wrong byte.
But again. only a concrete example could solve that mystery :bg

[Geryon]

I'm not familiary with the subject but disassembly doesn't have to be always correct.
Take a look at this code and its disasm.
Actual Code:

Code Select Expand


    mov eax, 20*0635186F1h
    cmp eax, 20*09CB16D48h
    je $+6
    mov eax, $+8
    jmp eax
    db 0D8h
    mov eax, 50*0635186F1h
    cmp eax, 50*09CB16D48h
    je $+6
    mov eax, $+8
    jmp eax
    db 0D8h
    invoke ExitProcess, -1


[dedndave]

it's strange that the disassembler did not synch up in the B8 opcode
that opcode has been the same since the 8088 - maybe even earlier
but that put it out of whack and it stayed out of whack all the way to INT3   :bg

well - i see it got a few more lines right
anyways - i would blame the disassembler for that one

[Twister]

Geryon,

I'm not sure what you are trying to prove. You miscalculated the jump and the disassembler is trying to understand the screwed up program. I would also mention that the values you try to set into the registers are beyond their capacities. So I wouldn't be surprised to see you get incorrect readings.

635186F1 x 14 = 7C25E8AD4  *Calculated in all hex.

:naughty:

[Geryon]

Thanks but no thanks :)
I did not miscalculated the jump, It is supposed to jump a middle of a instruction so the dissassembler (ollydbg in this case) would fail to disassemble.
And 20*0635186F1h, etc... that's just junk code doest mean anything and masm32 will truncate that to 32bit value. The magic is at the jumps

The program works well acutally. It's just call ExitProcess,-1.
These are commond techniques to trick dissassemblers.

[jj2007]

By the way: Oleg has released a new version on 3 August. From first tests, it looks more stable than previous ones. You may have to set the UDD folder explicitly, because it analyses a lot of OS code at every launch.

I wonder how other debuggers score on the test above...

[zemtex]

It has a few bugs, one of them is a scroll bug, the selection bars become unaligned with the mouse cursor.

[jj2007]

@Robert, see reply #1:
The wrong stack alignment is present up to MASM version 8.0. Version 9 and 10, and the latest JWasm version, work fine

[raleeper]

I'm not familiary with the subject but disassembly doesn't have to be always correct.
Take a look at this code and its disasm.
Actual Code:

Code Select Expand


   mov eax, 20*0635186F1h
   cmp eax, 20*09CB16D48h
   je $+6
   mov eax, $+8
   jmp eax
   db 0D8h
   mov eax, 50*0635186F1h
   cmp eax, 50*09CB16D48h
   je $+6
   mov eax, $+8
   jmp eax
   db 0D8h
   invoke ExitProcess, -1


My cases are more obvious.  In the dissassembly the code dissasembly lines don't match up with the comments and I recognize the dissasy as from a previous version.

Thanks, ral

[Twister]

example.s source:

Code Select Expand

ALIGN 8,DB 0

SECTION .data

_success:
db '> was able to complete the program',10
_len: equ $-_success

SECTION .text
global main
main:
mov eax, 0x635186F1
cmp eax, 0x09CB16D48
je $+6
mov eax, $+8
jmp eax
db 0xD8
mov eax, 0x635186F1
cmp eax, 0x9CB16D48
je $+6
mov eax, $+8
jmp eax
db 0xD8

mov edx, _len
mov ecx, _success
mov ebx, 1
mov eax, 4
int 0x80

mov ebx, 1
mov eax, 0
int 0x80

Code Select Expand

$ objdump -Mi386,intel -d example.o

example.o:     file format elf32-i386


Disassembly of section .text:

00000000 <main>:
   0: b8 f1 86 51 63        mov    eax,0x635186f1
   5: 3d 48 6d b1 9c        cmp    eax,0x9cb16d48
   a: 74 04                je     10 <main+0x10>
   c: b8 14 00 00 00        mov    eax,0x14
  11: ff e0                jmp    eax
  13: d8 b8 f1 86 51 63    fdivr  DWORD PTR [eax+0x635186f1]
  19: 3d 48 6d b1 9c        cmp    eax,0x9cb16d48
  1e: 74 04                je     24 <main+0x24>
  20: b8 28 00 00 00        mov    eax,0x28
  25: ff e0                jmp    eax
  27: d8 ba 23 00 00 00    fdivr  DWORD PTR [edx+0x23]
  2d: b9 00 00 00 00        mov    ecx,0x0
  32: bb 01 00 00 00        mov    ebx,0x1
  37: b8 04 00 00 00        mov    eax,0x4
  3c: cd 80                int    0x80
  3e: bb 01 00 00 00        mov    ebx,0x1
  43: b8 00 00 00 00        mov    eax,0x0
  48: cd 80                int    0x80

Problem with GAS with X86 fdiv, fdivr, etc.

[raleeper]

jj2007:  Is there a chance a later masm would avoid the bug you reported in Topic FormatMessage Error?

No, I used the latest one. The wrong stack alignment is present up to MASM version 8.0. Version 9 and 10, and the latest JWasm version, work fine

Well, it's nice to know that I can forget about v. 8, anyway.  I thought about just getting a later v. just on general principle and I could probably do that with v. 8, since it's available as a standalone, though I'd apparrently have to install Visual Studio.  I was a little afraid that the install/uninstall would screw up something I have now and that I'd have to go back to a restore point, something I'm always a little nervous about.  But if v.8 is defective I'll forget that.  A lot more seems to be needed just to get a later [v.10] ml.exe.  I don't want to go to the effort just for that one bug.

Think about DednDave's remark that most code is a mix of decimal and hex code anyway. Adding the h to all immediate integers is not a big job, although I understand your resistance, of course.

That's not the problem.  I am careful to never use decimal without the "d".

My reason for special interest now is that several times lately I have been debugging away when I notice the source doesn't match the dissambly, which means the last assembly failed - and I missed any error message.  For now the only thing I can do is be more careful to notice output from the assembly, and check when starting a DBG session that dissassembly matches source.

I think these occasions have all been while I was working on macros, and I think maybe the failures would not have occurred if masm used a third pass.  [So another thing I can do is avoid macros defined other than by methods I know work]

A concrete example would be helpful and interesting. Out of my belly, I can see only two reasons:
1. disassembly doesn't show macros (but lst files do)
2. Olly occasionally produces garbage listings, if it starts interpreting on the wrong byte.
But again. only a concrete example could solve that mystery :bg

I'll make notes the next time it happens.  I've always focussed on the error causing the failure and worked around that, and not stopped to focus on the circumstances of the assembly failure.

[jj2007]

Robert,

Instead of using MASM v10, go for the JWasm clone - download here, the last one in the list is the good one (207bw aka binary Windows).

The bug with the LOCALs is fixed, and otherwise JWasm works like a charm, much faster than MASM.

By the way, the original problem in your TestP source was in line 185:

Code Select Expand

invoke WinMain, hinst, 0, cmdl, SW_SHOWDEFAULT ; bad
invoke WinMain, hinst, 0, offset cmdl, SW_SHOWDEFAULT ; good


Masm up to version 8.0 pushes a WORD because cmdl is a byte variable; and thus the stack gets messed up.
JWasm and Masm 9/10 push a DWORD, which causes less problems in this case but is likely to cause, in other circumstances, bugs that are difficult to chase.

[raleeper]

Robert,

Instead of using MASM v10, go for the JWasm clone - download here, the last one in the list is the good one (207bw aka binary Windows).

The bug with the LOCALs is fixed, and otherwise JWasm works like a charm, much faster than MASM.

By the way, the original problem in your TestP source was in line 185:

Code Select Expand

invoke WinMain, hinst, 0, cmdl, SW_SHOWDEFAULT ; bad
invoke WinMain, hinst, 0, offset cmdl, SW_SHOWDEFAULT ; good


Masm up to version 8.0 pushes a WORD because cmdl is a byte variable; and thus the stack gets messed up.
JWasm and Masm 9/10 push a DWORD, which causes less problems in this case but is likely to cause, in other circumstances, bugs that are difficult to chase.

Wonderful!  A complete solution!  Thank you!

Still, I should have found the bug in line 185 myself, simply by looking at the dissasembly of that line and asking "What it it doing pushing a WORD?"
So the lesson I've learned (one of them anyway) is: when an invoke doesn't work, examine the dissasy.
Now that I know this, I think I prefer the MASM 6 reaction, which creates a more easily recognizable error.  With masm 10 or Jwasm the difference would be between "push dword ptr ...." and "push offset ...", either of which might be right.

[later] I thought I didn't use word variables, but looking at the code for my big program I found, out of hundreds of 'DD"s and "DB"s, 20 "DW"S.  7 are in accelerator tables and they have to stay, 4 are for data alignment (or to permit access of the word as a dword)  and there is a better way, and the first of the others I looked at was a worked-around error, the workaround unnecessary if I had just used DW in the first place.

Thanks again!

[raleeper]

I was wrong.  jj2007's bugfix did NOT fix the FormatMessage problem and the Child Window Invalidates Parent problems.
They are fixed with or without it, that is, with the correct command line parameter, "offset cmdl" or the wrong one, "cmdl".

It did, however, fix 2 other problems: Beep not working, and one I hadn't mentioned, Main screen misaligned.

What exactly fixed the first 2 remains a mystery, but the bugfix is definitely responsible for correcting the last 2.

Sorry about the error - post in haste, repent in leisure.

And no less thanks.

Best wishes, Robert