From patchwork Wed Feb 10 19:11:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 8274081 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 25B8A9F3CD for ; Wed, 10 Feb 2016 19:14:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 410A42039E for ; Wed, 10 Feb 2016 19:14:36 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2942E2037E for ; Wed, 10 Feb 2016 19:14:35 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aTaAe-00040n-TB; Wed, 10 Feb 2016 19:11:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aTaAd-000400-Br for xen-devel@lists.xen.org; Wed, 10 Feb 2016 19:11:23 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id DA/DB-21901-A5B8BB65; Wed, 10 Feb 2016 19:11:22 +0000 X-Env-Sender: prvs=84103137d=Andrew.Cooper3@citrix.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1455131480!21580568!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22155 invoked from network); 10 Feb 2016 19:11:21 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Feb 2016 19:11:21 -0000 X-IronPort-AV: E=Sophos;i="5.22,426,1449532800"; d="scan'208";a="330910690" To: Jan Beulich References: <1455048108-5045-1-git-send-email-andrew.cooper3@citrix.com> <1455048108-5045-9-git-send-email-andrew.cooper3@citrix.com> <56BB49CA02000078000D090C@prv-mh.provo.novell.com> <56BB3DEF.9040801@citrix.com> From: Andrew Cooper X-Enigmail-Draft-Status: N1110 Message-ID: <56BB8B56.4060703@citrix.com> Date: Wed, 10 Feb 2016 19:11:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <56BB3DEF.9040801@citrix.com> X-DLP: MIA2 Cc: Xen-devel Subject: Re: [Xen-devel] [PATCH 8/8] x86/efi: Generate uefi_call_wrapper() when compiling with clang X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 10/02/16 13:41, Andrew Cooper wrote: > On 10/02/16 13:31, Jan Beulich wrote: >>>>> On 09.02.16 at 21:01, wrote: >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Jan Beulich >>> >>> What is the GCC version check supposed to be achieving here? GCC has >>> supported this syntax since 3.0 >> This is best answered by looking at where we've got these headers >> from - the gnu-efi package. It has ... >> >>> --- a/xen/include/asm-x86/x86_64/efibind.h >>> +++ b/xen/include/asm-x86/x86_64/efibind.h >>> @@ -274,7 +274,7 @@ typedef uint64_t UINTN; >>> #endif >>> #endif >>> >>> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) >>> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) || __clang__ >>> #define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__) >>> #else >>> /* for x86_64, EFI_FUNCTION_WRAPPER must be defined */ >> /* for x86_64, EFI_FUNCTION_WRAPPER must be defined */ >> #if defined(HAVE_USE_MS_ABI) >> #define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__) >> #else >> UINTN uefi_call_wrapper(void *func, unsigned long va_num, ...); >> #endif >> #define EFI_FUNCTION __attribute__((ms_abi)) >> >> I think this makes clear that the needed feature here is the >> attribute, which certainly wasn't available in older gcc. >> >> With that the question is whether the Clang case won't also need >> a version check, since I can't imagine them having supported this >> prior to gcc introducing it. > Clang has an substantially more sane way than GCC of checking for > individual features. I will introduce and use the > __has_{attribute,feature}() infrastructure to tests like this. > > Experimentally, Clang 3.5 does have ms_abi support Looking at it further, this entire block is unsed. Nothing in tree refers to uefi_call_wrapper() or EFI_FUNCTION_WRAPPER other than this small bit; all declarations use EFIABI directly. i.e. this: #endif works correctly for GCC and clang. Would dropping this completely be acceptable? ~Andrew diff --git a/xen/include/asm-x86/x86_64/efibind.h b/xen/include/asm-x86/x86_64/efibind.h index af5f424..b013db1 100644 --- a/xen/include/asm-x86/x86_64/efibind.h +++ b/xen/include/asm-x86/x86_64/efibind.h @@ -274,17 +274,6 @@ typedef uint64_t UINTN; #endif #endif -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) -#define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__) -#else -/* for x86_64, EFI_FUNCTION_WRAPPER must be defined */ -#ifdef EFI_FUNCTION_WRAPPER -UINTN uefi_call_wrapper(void *func, unsigned long va_num, ...); -#else -#error "EFI_FUNCTION_WRAPPER must be defined for x86_64 architecture" -#endif -#endif - #ifdef _MSC_EXTENSIONS #pragma warning ( disable : 4731 ) // Suppress warnings about modification of EBP