From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2D73A81F5C for ; Fri, 2 Dec 2016 11:26:48 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 66E528F23F; Fri, 2 Dec 2016 19:26:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-87.phx2.redhat.com [10.3.116.87]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2JQi2C005607; Fri, 2 Dec 2016 14:26:45 -0500 To: Anthony PERARD References: <20161201152819.8341-1-anthony.perard@citrix.com> <53c67cb5-e947-8979-7738-288cc83f374b@redhat.com> <20161202160201.GA1848@perard.uk.xensource.com> Cc: Jordan Justen , "Gao, Liming" , "Zhu, Yonghong" , Ard Biesheuvel , edk2-devel@ml01.01.org From: Laszlo Ersek Message-ID: <9c0c9f43-a297-179f-2d57-fa5d8fab3763@redhat.com> Date: Fri, 2 Dec 2016 20:26:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161202160201.GA1848@perard.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 02 Dec 2016 19:26:47 +0000 (UTC) Subject: Re: [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 19:26:48 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/02/16 17:02, Anthony PERARD wrote: > On Thu, Dec 01, 2016 at 07:43:24PM +0100, Laszlo Ersek wrote: >> On 12/01/16 16:28, Anthony PERARD wrote: >>> Hi, >>> >>> That might be only with the Xen part of OVMF but now that the GCC5 >>> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail >>> to boot in Xen guests. >>> > [...] >>> >>> Removing the gcc option -flto in only the XenBusDxe module makes OVMF >>> boot. >>> >>> While trying to debug that, I've added some debug prints (in this module >>> and in XenPvBlkDxe), and the exception could change and become a "page >>> fault" instead, or even an assert failure in the PrintLib, that was the >>> ASSERT(Buffer != NULL) at I think >>> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366 >>> >>> Adding EFIAPI to internal functions in XenBusDxe makes things work >>> again. My guest is that gcc would bypass (optimise) an exported >>> functions and call directly an internal one but without reordering the >>> arguments (EFIAPI vs nothing). >>> >>> Does that make sense? >> >> If "-b NOOPT" works for you, I'd prefer that as a temporary solution >> (until the root cause is found and addressed) to the XenBusDxe patches. > > That works, using GCC49 (with gcc 6.2.1) works as well. > >> Hrpmf, wait a second, I do see something interesting: in this series you >> *are* modifying APIs declared in a library class header (namely >> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public >> libraries) *are* required to specify EFIAPI. >> >> What happens if you apply patch #1 only? > > With only XenHypercallLib changes, the error is the same. > > But I did find the minimum change needed, it envolve a function with a > VA_LIST as argument. > > With only the following patch, OVMF works again. > > diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c > index 1666c4b..85b0956 100644 > --- a/OvmfPkg/XenBusDxe/XenStore.c > +++ b/OvmfPkg/XenBusDxe/XenStore.c > @@ -1307,6 +1307,7 @@ XenStoreTransactionEnd ( > } > > XENSTORE_STATUS > +EFIAPI > XenStoreVSPrint ( > IN CONST XENSTORE_TRANSACTION *Transaction, > IN CONST CHAR8 *DirectoryPath, > diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h > index c9d4c65..33bb647 100644 > --- a/OvmfPkg/XenBusDxe/XenStore.h > +++ b/OvmfPkg/XenBusDxe/XenStore.h > @@ -209,6 +209,7 @@ XenStoreSPrint ( > indicating the type of write failure. > **/ > XENSTORE_STATUS > +EFIAPI > XenStoreVSPrint ( > IN CONST XENSTORE_TRANSACTION *Transaction, > IN CONST CHAR8 *DirectoryPath, > IN CONST CHAR8 *Node, > IN CONST CHAR8 *FormatString, > IN VA_LIST Marker > ); > > > I think the exception happen when this function is called via > XENBUS_PROTOCOL->XsPrintf() from XenPvBlockFrontInitialization() in > OvmfPkg/XenPvBlkDxe/BlockFront.c > It used to be a known requirement / limitation that all functions with variable argument lists had to be EFIAPI, regardless of cross-module use. However, commit 48d5f9a551a93acb45f272dda879b0ab5a504e36 changed that, and varargs should "just work" now. I suspect this is a __builtin_ms_va_* regression in gcc-6. Thank you for narrowing it down. It might make sense to report a bug in the upstream gcc tracker. ... Oh wow, this is a known gcc bug! See: https://lists.01.org/pipermail/edk2-devel/2016-August/001018.html Upstream gcc BZ was apparently solved for "Target Milestone: 6.3" (your version is 6.2.1). So we'll either need a GCC6 toolchain in BaseTools that drops -flto, in order to work around this gcc issue, or we'll have to ask gcc-6 users to use at least gcc-6.3. Oh wait, gcc-6.3 hasn't been released yet. We need the BaseTools workaround then. Thanks! Laszlo