OPTION PROLOGUE:NONE not working

[y-code]

I have a proc in an otherwise working app. I have set OPTION PROLOGUE:NONE and OPTION EPILOGUE:NONE before it correctly, yet the assembler/linker is stubbornly refusing to honour this and is inserting stack handling/leaving code. I address ESP directly in the proc, yet OllyDBG shows this code is being (inconsistently) altered to reference by EBP, which obviously breaks the code, as I need to use EBP as a working register. I have tried commenting out the input parameters and altering the PROTO to remove them, so there is no apparent reason why it should think this procedure is not a parameterless proc, yet even this doesn't work.

Under what circumstances would MASM refuse to honour my directive and force stack frames on me in this way? How can I stop this?

Yeah, should have said that there are other parametered procs in this app that are working correctly with this directive, whch also access ESP freely without problems. I have no idea why this one is being assmebled differently.

[P1]

Post the offending code.

Regards,  P1  :8)

[PBrennick]

y-code,
Are you will  to post that particular procedure, in its entirety, with absolutely no changes so I can run it through my testbed.

Paul

[PBrennick]

Sorry P1, we cross posted,
Paul

[Vortex]

y-code,

Here is an example from masm32.lib , the procedure has no automated stack handling code :

Code Select Expand

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    .486
    .model flat, stdcall
    option casemap :none   ; case sensitive

    .code

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

align 4

StrLen proc item:DWORD

  ; -------------------------------------------------------------
  ; This procedure has been adapted from an algorithm written by
  ; Agner Fog. It has the unusual characteristic of reading up to
  ; three bytes past the end of the buffer as it uses DWORD size
  ; reads. It is measurably faster than a classic byte scanner on
  ; large linear reads and has its place where linear read speeds
  ; are important.
  ; -------------------------------------------------------------

    mov     eax,[esp+4]             ; get pointer to string
    push    ebx
    lea     edx,[eax+3]             ; pointer+3 used in the end
  @@:     
    mov     ebx,[eax]               ; read first 4 bytes
    add     eax, 4                  ; increment pointer
    lea     ecx,[ebx-01010101h]     ; subtract 1 from each byte
    not     ebx                     ; invert all bytes
    and     ecx,ebx                 ; and these two
    and     ecx, 80808080h
    jz      @B                      ; no zero bytes, continue loop

    test    ecx,00008080h           ; test first two bytes
    jnz     @F
    shr     ecx,16                  ; not in the first 2 bytes
    add     eax,2
  @@:
    shl     cl,1                    ; use carry flag to avoid branch
    sbb     eax,edx                 ; compute length
    pop     ebx

    ret     4

StrLen endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end

[Tedd]

Make sure you're not referencing/accessing any arguments or local variables by name, or it will insert the appropriate ebp accesses.
Otherwise, I don't know why it would do that.

[y-code]

I had a hunch... I was using the same internal parameter names in the proc as in another slightly altered version, and this seems to have caused a collision. When I altered the parameter names slightly, it assembled fine. I can only guess it was the references in the other proc that were causing this. As Tedd advised, I'd already removed all references in the problem proc to parameter names, using only direct [ESP+offset] references, and there were no local variables.

I'd say this is a MASM bug - if you aren't using OPTION:NOSCOPED then local variables or parameter names or labels inside a proc should be totally private to the proc, and shouldn't affect the assembling or linking of any other proc at all.

[MichaelW]

I tried every oddball thing that occurred to me, including assessing arguments and locals by name, and now including two identical procedures with the only differences being the procedure names and the prologue and epilogue options, and I cannot duplicate the described behavior. What version of MASM are you using?

[PBrennick]

So did I, he probably had a stack crash caused by improperly referencing a local variable.  Especially after reading what he last said.

Paul

[y-code]

Very odd.  :eek I just renamed the parameters back to the "colliding" names and it assembles fine. I swear I didn't change a single other line of code. This has had me running round in circles all afternoon, cos I know it was right before and it's no different now. As the identical code works fine now it's pointless posting it, and its not terribly useful anyway.

@Michael, I have 6.15 added to the latest MASM32 distribution, assembling in WinASM.

@PBRennick, I'm capable of counting in 4s correctly to reference stack parameters, thankyou.  :boohoo:  I explained clearly that the error was showing up in OllyDBG that my explicit ESP stack references were being coded as EBP offsets instead. Mostly. That had nothing to do with mis-referencing parameters.

[PBrennick]

 :boohoo: You miss the point.  The machine is also counting in 4s at the same time. I have said all I will say baecause you will not listen anyway.  Call it your bug and give it a name.

Paul

[y-code]

he probably had a stack crash caused by improperly referencing a local variable

As Tedd advised, I'd already removed all references in the problem proc to parameter names, using only direct [ESP+offset] references, and there were no local variables.

Whatever. I know I changed nothing else but some paramater names, and OK code that had been assembling wrongly all afternoon, that I'd tried multiple ways of recoding around this refusal to remove stack frames, suddenyl started assembling. Glitch or bug, I'm just reporting it. Don't shoot the messenger.

[PBrennick]

If you can not reproduce it, it does not exist.

[Mark Jones]

I know! Someone must have forgot to include

Code Select Expand


.option bugs=off


:bdg

[y-code]

All very funny. Hoho. I'm laughing.

If you can not reproduce it, it does not exist.

Patently untrue. It just means there may be more input factors involved than have been tested to date in attempting to reproduce the error.

Perhaps if you'd been less rude than to "reply" to me in the third person and as if I was too ignorant to have any sort of handle on the problem, despite having expressed it clearly and thoroughly and having enough experience to try a number of alternative solutions on my own, then your normally good advice might have been better received.