[llvm-commits] [WinABI patch] Make sure to call __chkstk when appropriate

Cameron Esfahani dirty at apple.com
Wed Aug 18 18:35:02 PDT 2010

Anton and I had a discussion about this and I think this updated version of the patch resolves most of the issues.

The long and the short of it is that Microsoft changed the functionality of __chkstk in the 64-bit case.  Previously __chkstk, like __alloca, would touch the stack and adjust the stack pointer.  In the 64-bit case, __chkstk is only responsible for touching the stack.  The 64-bit prologue code is responsible for adjusting the stack pointer.

In this new patch, I have added the 32-bit Windows case to the existing CygMing logic, and call __chkstk instead of __alloca.  The 64-bit Windows case is on its own.  I also put a nice big comment explaining how the 64-bit version of __chkstk has different functionality than the 32-bit version.

One question that I have, though: should we treat 64-bit CygMing like 64-bit Windows?  Does the 64-bit __alloca implementation in CygMing adjust the stack pointer?  Current, the logic in emitPrologue() is that the all flavors of CygMing (32 and 64-bit) go through the 32-bit CygMing/Windows path?

Based on revision 111498:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stack.patch
Type: application/octet-stream
Size: 6739 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100818/c1c44b5f/attachment.obj>
-------------- next part --------------

On Aug 18, 2010, at 3:56 AM, Anton Korobeynikov wrote:

> Hello, Cameron
>> I put it in the same area as the mingw case, for __alloca, so I thought it
>> was in the right place.
> Hrm... Doesn't seem so. Stuff really should be done inside emitPrologue(),
> not within some helper routine.
>> You're right it will clobber eax in the 32-bit case, so there'd have to be
>> some code added to save/restore it.
> emitPrologue() already handles this case for __alloca, no need to code
> duplication,
> you'll just have to tune the name there.
>> I'll have to take your word that __chkstk is the same as __alloca, but
>> reading the documentation on Microsoft's website, it doesn't come across
>> that way:
>> __alloca:
>> Allocates memory on the stack. This function is deprecated because a more
>> secure version is available; see _malloca.
> MS __alloca != mingw32 __alloca
>> The __chkstk helper will not modify any registers other than R10, R11, and
>> the condition codes. In particular, it will return RAX unchanged and leave
>> all nonvolatile registers and argument-passing registers unmodified.
>> So, the only registers which are munged, in the 64-bit case, are the
>> volatile ones.  I assumed that the 32-bit case would be similar.
> There is one point
>> The reason I didn't add this code to the mingw case is because that path
>> never calls emitSPUpdate():  it relys on __alloca to do all the stack
>> manipulation.  This didn't  appear to me that it would be valid, according
>> to the Windows ABI.
> It definitely does all the stack manipulations, see above. I'm not quite sure
> about 64 bit case. I vague recall some discussion on gcc ML, that on 64 bit
> __chkstk != __alloca
> -- 
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University

Cameron Esfahani
dirty at apple.com

"There are times in the life of a nation when the only place a decent man can find himself is in prison."

More information about the llvm-commits mailing list