[cfe-dev] [LLVMdev] Fwd: Handling SRet on Windows x86

[Reid Kleckner]

On Thu, Mar 28, 2013 at 8:59 AM, Joe Groff <arcata at gmail.com> wrote:

> On Thu, Mar 28, 2013 at 8:55 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <arcata at gmail.com> wrote:
>>
>>> On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>>
>>>> This is why I suggest that the Windows ABI is whatever MSVC happens to
>>>> do. The mingw ABI happens to consist of a conjunction of what MSVC does for
>>>> C and what GCC on Linux does for C++. That is a unique and different ABI,
>>>> and I don't think you can reasonably call it *just* "windows" at any point.
>>>>
>>>> This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the
>>> C level—for instance, alignment of pass-by-value structs sometimes differs,
>>> and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw.
>>> There are other differences too.
>>>
>>
>> Can you clarify what you mean by the "sret pointer is callee-cleanup" vs
>> caller-cleanup?
>>
>
> In the epilog for a function with an indirect struct return argument, MSVC
> emits a 'ret 4' to pop the return pointer argument. Mingw emits a 'ret'.
>
>
>> What we were specifically hitting yesterday was that MSVC expects the
>> sret pointer passed into also be returned in eax.  LLVM already does this
>> for x86_64 everywhere.  Mingw doesn't do this, but I think it was just a
>> coincidence.  This behavior was undocumented, and that there was probably
>> no OS API takes a callback which returns a struct larger than 8 bytes.
>>
>> This makes me think that it would be better if we started returning the
>> sret pointer from such functions under Mingw for improved compatibility at
>> the C ABI level.  This shouldn't break any mingw code so far as I can tell.
>>  It seems reasonable for a user to expect that the Mingw and Microsoft C
>> ABIs be compatible, but maybe there are enough other corner cases that this
>> is just naive.
>>
>
> Good catch. Returning the sret pointer in eax shouldn't affect Mingw
> compatibility since EAX isn't preserved across calls in either the
> Microsoft or Mingw ABIs (IIRC).
>

Yeah, but the ret / ret 4 discrepancy means they're still fundamentally
incompatible, so this wouldn't help.  =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130328/9acf558f/attachment.html>