invoke DrawText, hdc,ADDR dbgw,12, ADDR rect, tfmt
00000268 68 00000150 * push +000000150h
0000026D 68 0000051C R * push OFFSET rect
00000272 6A 12 * push +000000012h
00000274 68 0000052C R * push OFFSET dbgw
00000279 FF 75 FC * push dword ptr ss:[ebp]+0FFFFFFFCh
0000027C E8 00000000 E * call DrawTextA
00000281 E8 00000004 call erbeep
ret
00000286 C9 * leave
00000287 C2 0010 * ret 00010h
This is part of a subroutine in my WndProc
The coding of "ret" as C9 C2 010 is wrong.
There is no problem with erbeep, which is global.
By trial I've found a workaround - insert an NOP after the invoke - inelegant to say the least.
What's going on?
The coding looks correct to me. Try posting your source.
MichaelW - "The coding looks correct to me. Try posting your source."
Well, it's coding correctly now, with ret as C3, and no workaround, so I must have been making some dumb mistake.
The source is at http://raleeper.com, but I haven't yet figured out how to make it easy to access.
Thanks.
Ok, looking at your source I think I see what you are doing. For a subroutine C3 is the correct encoding, and you can force this encoding by using RETN instead of RET.
Quote from: MichaelW on May 16, 2007, 11:37:38 PM
Ok, looking at your source I think I see what you are doing. For a subroutine C3 is the correct encoding, and you can force this encoding by using RETN instead of RET.
I tried retn with no success when I was having the problem. Now the simple ret works.
The problem - ret coded as C9 C2 10 and no return/crash - popped up again after I made changes in the subroutine.
This time nop didn't work, but retn did.
So you were right. Thanks.
hihihihi
What a joke...
Since when do assemblers encode a RET wrongly? eh?
That encoding might serve a purpose ... ;)
ret - Wrapup
The masm32 assembler, while processing a proc, assumes that any "ret" is an exit from the proc, although this assumption can be overridden by using "retn", or "retf", and procs can be nested.
It does this for policy reasons (subroutines other than declared procedures are "disparaged").
This is guesswork to a large extent, but I believe it is accurate.
Quote from: raleeper on May 21, 2007, 11:16:06 AM
ret - Wrapup
The masm32 assembler, while processing a proc, assumes that any "ret" is an exit from the proc, although this assumption can be overridden by using "retn", or "retf", and procs can be nested.
Slightly wrong....
MASM does offer PROC as a feature. This feature does help you with automatic handling of LOCAL variables, USES handling, parameter count and type checking (if PROTO is used) and the clearing of the stack according to defined calling convention. Honestly it does help quite a lot and like any helper it does have some caveats.
Of course you can always code all this by hand... and maybe you should do so until you fully understand the help and usage of PROC.
I am unsure if you can really overwrite all this with a RETN... in fact with a USES clause a series of POP's should precede any RET. Maybe you can but why? The idea is that you are playing with fire and for no real reason
In order to nest PROC's ?... What kind of a joke is this? Why should anybody want to nest PROC's?
Just in order to create problems? IF you really really want to nest them then you should be doing it manually and look into ENTER and LEAVE opcode description in Intel manuals. AFAIK ENTER was designed for this.
Quote
It does this for policy reasons (subroutines other than declared procedures are "disparaged").
Wrong!
MASM does this in order to help you... you are trying to "bend/abuse" it's help for a purpose it was not designed to serve...
You can always code "nested procedures" by hand...
> I am unsure if you can really overwrite all this with a RETN... in fact with a USES clause a series of POP's should precede any RET
Yes, you can. There is no "hidden "code inserted with RETN.
> In order to nest PROC's ?... What kind of a joke is this? Why should anybody want to nest PROC's?
I don't "nest" PROCs, but use the RETN to exit "local" functions like this:
main proc uses esi edi
mov eax,1
call localfunc1
ret
localfunc1:
xchg eax,edx
retn
main endp
> Just in order to create problems?
What problems? There is nothing wrong using local functions IMO.