Subj : Re: BC++ 5.02 Stack Restore Bug
To   : borland.public.cpp.borlandcpp
From : kurt jensen
Date : Wed Dec 01 2004 09:10 am

thanks Ed!!!  you hit it right on the head!

the vendor provides a DLL of C functions where none of functions is
prefaced with an underscore (_).  I had to preface all the declarations
with _stdcall in order to convince Borland to link and run.  BUT, the
functions are NOT __stdcall and do NOT clean up the stack.  now I will
have to negotiate with the vendor or force my function to allocate some
automatic variables in order to make the stack correct before return.


"Ed Mulroy [TeamB]" wrote:
> 
> It's just a guess but look at the options settings.  One of the options is
> to
> use a standard stack frame.  Check if it is disabled.
> 
> Note: if you change an option setting, then do a Project|Build instead of a
> Project|Make to force the changes to be reflected in all the object files.
> 
> However, looking at the TSCOR20CaptureThread::IncrCaptureOk function in that
> assembly listing, I do not see why 'mov esp,ebp' would be required.  The
> stack pointer is never altered to provide automatic storage and the the
> value of esp at the end is correct for doing the pop or the two pushed
> register values.
> 
> With C++ calling conventions, each function is responsible for preserving
> the value in esp.  I see a call to flycaptureUnlock.  You might want to look
> at the register values before and after that call.
> 
> That the code does not clean up the space on the stack for the calling
> arguments after the return implies that flycaptureUnlock is a __stdcall
> (WINAPI) function, the type that cleans up the space on the stack itself
> with a command such as
>     RET 6.
> Try looking at what it actually does.
> 
> .  Ed
> 
> >kurt jensen wrote in message
> > news:41AD052D.357F9A3A@SPAMspiricon.com...
> >
> > for some perverse reason my Borland C++ 5.02 compiler has
> > decided to pull funny tricks on me.  after spending a week
> > blaming the DLL vendor I stumbled onto a "situation" in the
> > assembly representation of my compiled code.
> >
> > everything looks fine until you get to the "ret" statement - then
> > we ALWAYS return to address 0x00000000.  the reason is that
> > the compiler left out one very important statement, "mov esp,ebp",
> > i.e.  the stack pointer is NEVER restored before popping ebp and
> > 'ret'urning from the function call.  because of that, we always try to
> > return to the wrong address which is always 0 because of a
> > parameter in a function call.
> >
> > anybody seen this particular problem before???  anybody have any
> > idea what would possess the compiler to pull such a stunt???  and,
> > more  importantly, how can I convince it to properly restore the
> > stack before returning???
> >
> > TIA,
> >
> > Kurt
> >
> >
> > below is the "C++ to Assembler" representation of the problem.  notice
> > at the end after label @156, we properly pop ebx, "mov esp,ebp" is
> > missing, pop ebp, and 'ret'urn.
> >
> >
> > @TSCOR20CaptureThread@IncrCaptureOk$qi proc near
> > ?live1@3616:
> >    ;
> >    ; bool TSCOR20CaptureThread::IncrCaptureOk(int buffer)
> >    ;
> > ?debug L 779
> > push      ebp
> > mov       ebp,esp
> > push      ebx
> > mov       eax,dword ptr [ebp+12]
> > mov       ebx,dword ptr [ebp+8]
> >    ;
> >    ; {
> >    ; FlyCaptureError CameraError;
> >    ;
> >    ; if (buffer > 0)
> >    ;
> > ?debug L 783
> > ?live1@3632: ; EBX = this, EAX = buffer
> > @152:
> > test      eax,eax
> > jle       short @153
> >    ;
> >    ; {
> >    ; CameraError = flycaptureUnlock(FCameraContext, buffer-1);
> >    ;
> > ?debug L 785
> > dec       eax
> > push      eax
> > push      dword ptr [ebx+22]
> > call      flycaptureUnlock
> >    ;
> >    ; if (CameraError == FLYCAPTURE_OK)
> >    ;
> > ?debug L 786
> > ?live1@3664: ; EBX = this, EAX = CameraError
> > test      eax,eax
> > jne       short @155
> >    ;
> >    ; CaptureOK++;
> >    ;
> > ?debug L 787
> > ?live1@3680: ; EBX = this
> > inc       dword ptr [ebx+30]
> >    ;
> >    ; } // then, started
> >    ;
> > ?debug L 788
> > ?live1@3696: ;
> > jmp       short @155
> >    ;
> >    ; else
> >    ; {
> >    ; CaptureOK++;
> >    ;
> > ?debug L 791
> > ?live1@3712: ; EBX = this
> > @153:
> > inc       dword ptr [ebx+30]
> >    ;
> >    ; } // else
> >    ;
> >    ; return true;
> >    ;
> > ?debug L 794
> > ?live1@3728: ;
> > @155:
> > mov       al,1
> >    ;
> >    ; } // TSCOR20CaptureThread::IncrCaptureOk()
> >    ;
> > ?debug L 795
> > @157:
> > @156:
> > pop       ebx
> > pop       ebp
> > ret
> > ?debug L 0
> > @TSCOR20CaptureThread@IncrCaptureOk$qi endp

.