[PATCH] Bug 14984 - Implement __attribute__((ms_abi))

Benno Rice benno at freebsd.org
Tue Jun 11 15:02:14 PDT 2013


On 12/06/2013, at 7:52 AM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Tue, Jun 11, 2013 at 3:44 AM, Benno Rice <benno at freebsd.org> wrote:
>> Hi all,
>> 
>> I've attached a patch to the bug at:
>> 
>> http://llvm.org/bugs/show_bug.cgi?id=14984
>> 
>> that implements the necessary glue to support __attribute__((ms_abi)).
>> 
>> If anyone has any questions, please let me know off-list.
> 
> It's not clear to me that representing this as a separate calling
> convention in Clang is the right approach. We support at least four
> different calling conventions when targeting the MS ABI (__cdecl,
> __fastcall, __stdcall, __thiscall); perhaps this attribute should be
> mapped to the appropriate member from that set? What should
> __attribute__((ms_abi)) do when we're targeting the MS ABI already?
> (Do you get a canonically-different type, or the same type, or is it
> an error?)

Well it most appropriately maps to stdcall but if you try to use stdcall on a non-Windows target it'll error out. The use-case for this change is non-Windows code that needs to use Microsoft calling conventions, the two known being WINE and, in my case, writing code that needs to call into UEFI. On Windows targets it should probably be an error or a no-op.

This attribute was added in GCC 4.6 or 4.7 for largely the use cases I described above.

If it's easier to map it to stdcall or something like that I'm happy to switch to that so long as the outcome's equivalent. I'm just not sure how to achieve that.

Cheers,
	Benno.



More information about the cfe-commits mailing list