Is there static analysis tools for x86 assembler?

[jj2007]

... make debugging easier - it's usually easier to fix a crash than to have some register contents being silently destroyed. If you don't want this feature...

That's really a feature, honestly. The point is that you normally preserve esi edi ebx on top, and on exit you pop them. If you do that with xx proc uses esi edi ebx or 'by hand' doesn't matter, in any case the leave before ret ensures that the proggie does return correctly - but your esi edi ebx contain garbage, and that problem may not show up for a while but it certainly will after you delivered the "release version" to your clients ;-)

[Antariy]

I had to read a few misconceptions here concerning the behavior of some assemblers that I'll try to correct:

• both masm and jwasm won't generate a stack frame if a proc has neither parameters nor locals. You can force the assemblers to generate a frame anyway by the user parameter <forceframe>
• both masm and jwasm will generate a stack frame if either parameters or locals are detected
• jwasm will, on certain occasions, generate a simple "POP EBP" instead of "LEAVE" as epilogue code. This is not to reduce "cycle counts" or save space but to make debugging easier - it's usually easier to fix a crash than to have some register contents being silently destroyed. If you don't want this feature, it can be turned off by option -Zg

Hope this helps, boys! 

Obviously it helps :t The main point of "some assemblers behaviour" was in that some of them restore esp value before return, and some do not restore it. As for me - with having no desire to test every code piece with "some different assemblers", I just guessed this "behaviour" from the results of execution (MASM - no crash, JWasm - there is crash), even didn't bother to assemble the code

... make debugging easier - it's usually easier to fix a crash than to have some register contents being silently destroyed. If you don't want this feature...

That's really a feature, honestly. The point is that you normally preserve esi edi ebx on top, and on exit you pop them. If you do that with xx proc uses esi edi ebx or 'by hand' doesn't matter, in any case the leave before ret ensures that the proggie does return correctly - but your esi edi ebx contain garbage, and that problem may not show up for a while but it certainly will after you delivered the "release version" to your clients ;-)

Jochen, you, as real macro guru (do not try to decline this statement  ;)), may write your own prologue and epilogue macroses, which will, beside of some other useful things, check the regs to be trashed at return :t Actually, I have almost written something like this, but in addition it had locals cleaning, stack probing, the return address checking (buffer overflows check) and I got bored to write that stuff. It doesn't that much required in progs if one is writing code right way.