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 295E781EB1 for ; Fri, 2 Dec 2016 01:45:41 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 85A397DCE4; Fri, 2 Dec 2016 09:45:40 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-74.phx2.redhat.com [10.3.116.74]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB29jc7K026452; Fri, 2 Dec 2016 04:45:39 -0500 To: Jordan Justen , Anthony PERARD , "Gao, Liming" , "Zhu, Yonghong" , Ard Biesheuvel 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> <148064028541.29053.2113052584622757913@jljusten-ivb> Cc: edk2-devel@ml01.01.org From: Laszlo Ersek Message-ID: <721cf7cb-4c3e-ac75-4623-44c80690aa6b@redhat.com> Date: Fri, 2 Dec 2016 10:45:38 +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: <148064028541.29053.2113052584622757913@jljusten-ivb> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 02 Dec 2016 09:45:40 +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 09:45:41 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/02/16 01:58, Jordan Justen wrote: > 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 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? >>> >>> 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. Got it now. :) Thanks! Laszlo > 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