From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 5DB0081F20 for ; Thu, 1 Dec 2016 16:58:06 -0800 (PST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP; 01 Dec 2016 16:58:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,284,1477983600"; d="scan'208";a="37877959" Received: from awillke-mobl1.amr.corp.intel.com (HELO localhost) ([10.252.136.252]) by orsmga005.jf.intel.com with ESMTP; 01 Dec 2016 16:58:05 -0800 MIME-Version: 1.0 To: Laszlo Ersek , "Anthony PERARD" , "Gao, Liming" , "Zhu, Yonghong" , "Ard Biesheuvel" Message-ID: <148064028541.29053.2113052584622757913@jljusten-ivb> From: Jordan Justen In-Reply-To: <914ffc38-90fe-4ded-4566-49f8e3112605@redhat.com> Cc: edk2-devel@lists.01.org References: <20161201152819.8341-1-anthony.perard@citrix.com> <53c67cb5-e947-8979-7738-288cc83f374b@redhat.com> <148062277652.26637.1503158876001098261@jljusten-ivb> <914ffc38-90fe-4ded-4566-49f8e3112605@redhat.com> User-Agent: alot/0.3.7 Date: Thu, 01 Dec 2016 16:58:05 -0800 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 00:58:06 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2016-12-01 12:54:34, Laszlo Ersek wrote: > On 12/01/16 21:06, Jordan Justen wrote: > > On 2016-12-01 10:43:24, Laszlo Ersek wrote: > >> Hrpmf, wait a second, I do see something interesting: in this series y= ou > >> *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? > > = > > I agree that this should be fixed. > > = > > But, if it works, I'm concerned that it would just be hiding a bug. My > > understanding was that the EFIAPI on libraries was needed so that a > > library implementation could be assembly based if desired. In this > > case C is used for the implementation, so the calling conventions > > should align. > = > Never tried the following, so I'm unsure if edk2 intends to support it > explicitly, but what about binary-only library instances (the 2-clause > BSDL allows that)? Good point. Once again, I agree that it is a bug that needs to be fixed. The functions in the library interface should have EFIAPI. I was just pointing out that I don't think it *ought* be the issue here since both side are C, and being built by the same compiler. Like you mentioned ... maybe it is a compiler bug, or a bug with our build flags. -Jordan > If the library class header doesn't state EFIAPI on the functions, the > library vendor builds the library instance with Visual Studio, and the > library user builds the client module with gcc (against the same library > class header), calls will fail. > = > (The way I imagine using binary-only library instances is that the > library comes as a binary object with a matching INF file, in a separate > subdirectory, and the user resolves the library class in his/her > platform DSC to that INF file. Not sure about the exact [section names] > in the library instance's INF file though.) > = > Thanks! > Laszlo