Re: [Patch 1/2] BaseTools: Add -D NO_MSABI_VARGS to X64 XCODE5 CC_FLAGS

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 19 May 2017 at 17:46, Andrew Fish <afish@apple.com> wrote:
>
> On May 19, 2017, at 5:49 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
>
> On 19 May 2017 at 07:52, Michael Kinney <michael.d.kinney@intel.com> wrote:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=561
>
> Update BaseTools/Conf/tools_def.template to add the define
>
> -D NO_MSABI_VAARGS
>
> To CC_FLAGS for X64 XCODE5 builds.
>
> The llvm/clang compiler used in XCODE5 builds supports the
> _ms_ versions of the vararg builtins, but the compiler
> generates build errors.
>
> The recommendation from the XCODE5 experts is to never use
> the _ms_ version of the vararg builtins.  The define
> NO_MSABI_VARARGS is already supported in MdePkg/Include/Base.h
> and forces the use the standard vararg builtins.
>
>
> Are such builds compliant with the UEFI spec?
>
>
> Ard I think you are confusing implementation and architecture. The UEFI Spec
> quotes an ABI, and __builtin_ms_* is a non standard compiler extension.
>
> Clang was designed to be a cross compiler and for X64 (x86_64) we set the
> arch to clang via -target x86_64-pc-win32-macho. Basically this tells clang
> it is an x86_64 (X64) arch, with a Windows ABI (EFI ABI), and produce a
> Mach-O Executable (for debugging). So the default var args builtin does the
> right thing for the EFI ABI, and __builtin_ms_* is not supported. The
> x86_64-pc-win32-macho triple is only used for EFI and when I talked to the
> clang folks they were like why do you need __builtin_ms_* when it is the
> same as __builtin_*, please fix your include files.
>

Thanks for clarifying. What confused me is the use of NO_MSABI_VAARGS,
which to a casual reader may seem to force a varargs ABI different
from the MS one, which is exactly what it is used for in libraries
such as OpensslLib IIRC.

In any case, if the clang target setting already fully defines the
varargs flavor of __builtin_va_xxx calls, then I suppose the resulting
code should be compliant. It may still be worthwhile to rename the
preprocessor macro to something more intuitive, but I won't insist.

Thanks,
Ard.