From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6239B21A16EFC for ; Fri, 19 May 2017 09:56:21 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id o12so51058902iod.3 for ; Fri, 19 May 2017 09:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9og3YfJTvxW7sBWWr8gqJJrzwGyLRpSKbFD67b+jjZg=; b=cDogKY3CnTEHbmISoGeDM8ohEyi1pGNaZe1gV5DncXJoigRznmrUY4SYvCCxgwgpZL c5pxPLEzfT3+De3bBeMz8r1yk/Yb+jTmwH8Xc2LkE5ANFoixW9Sk2gszWgpm5RcQdLDB DH7MJXR9UfklKg9xKUFZtf/mRvbGDfk58k/ng= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9og3YfJTvxW7sBWWr8gqJJrzwGyLRpSKbFD67b+jjZg=; b=Qe6iyS/nK8incSdQM9ma848Uqlbz+Tg1nNUlNMb6T6VwS3mQPqBY155IJw6JGwirg4 0SovXHsf8/UeW2nVMoQRhw9OOfY7CAzM/TRL52CpFEwwlmueoy6nXno295Wr/4POb6a+ sw1jJays14cmLEC6WlJXLAfbmGF5/y6rn5SkUp92KkteDhsimZx/Il7KfiJCSkYl8LSt +q3U/mFBq7+zBqV2JcTrzzqkSf42LfEZ1Oke/+cu1yCckwvqyQ+559vAxYyOOzoUPRnR j7NEd8AmnXZUSmFb02JHGIgm2pQz+403nDg3bqxNNkgI3oJXAPhHoxtxDCVVqo79dAFm Ni6g== X-Gm-Message-State: AODbwcDLTCDH2BUHdJJGWoAUnxnxU5pY34YCo+f2IPTS8l4jIO3S2LBu UED/zdFwxbctXQ8EW9lyJS4kXa6aW3ln X-Received: by 10.107.180.130 with SMTP id d124mr10784628iof.47.1495212980698; Fri, 19 May 2017 09:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.24 with HTTP; Fri, 19 May 2017 09:56:20 -0700 (PDT) In-Reply-To: <208C5E91-D18A-4442-AA6B-AFDC1455D9E5@apple.com> References: <1495176736-28376-1-git-send-email-michael.d.kinney@intel.com> <1495176736-28376-2-git-send-email-michael.d.kinney@intel.com> <208C5E91-D18A-4442-AA6B-AFDC1455D9E5@apple.com> From: Ard Biesheuvel Date: Fri, 19 May 2017 17:56:20 +0100 Message-ID: To: Andrew Fish Cc: Mike Kinney , "edk2-devel@lists.01.org" , Liming Gao Subject: Re: [Patch 1/2] BaseTools: Add -D NO_MSABI_VARGS to X64 XCODE5 CC_FLAGS X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:56:21 -0000 Content-Type: text/plain; charset="UTF-8" On 19 May 2017 at 17:46, Andrew Fish wrote: > > On May 19, 2017, at 5:49 AM, Ard Biesheuvel > wrote: > > On 19 May 2017 at 07:52, Michael Kinney 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.