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

[Cameron Esfahani]

On Aug 18, 2010, at 2:43 AM, Anton Korobeynikov wrote:

> Hello, Cameron
> 
>> Windows ABI requires the function prologue to call __chkstk if there is >= 4096 bytes allocated on the stack.
> The patch is invalid due to many reasons:
> - It does the stuff in wrong place

I put it in the same area as the mingw case, for __alloca, so I thought it was in the right place.

> - It clobbers eax which can be incoming arg reg in case of inreg
> params / fast CC

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.

> - __chkstk is same as __alloca call in mingw case, which is already implemented
> 

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.
> 

__chkstk:
> Called by the compiler when you have more than one page of local variables in your function.
> 

> Also, I don't recall offhand, but iirc this call had some special CC,
> it clobbers quite alot of regs, etc.


According to the Microsoft website:

> 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.

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.

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."



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100818/452400e6/attachment.html>