From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.93; helo=mga11.intel.com; envelope-from=jordan.l.justen@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 35A96211E2EE1 for ; Sun, 31 Mar 2019 23:17:13 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2019 23:17:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,295,1549958400"; d="scan'208";a="157018412" Received: from achutan-mobl2.amr.corp.intel.com (HELO localhost) ([10.254.21.54]) by fmsmga002.fm.intel.com with ESMTP; 31 Mar 2019 23:17:12 -0700 MIME-Version: 1.0 In-Reply-To: <46E887C8-DAAB-4855-BB70-69066F6B45FD@apple.com> References: <20190315051749.6564-1-zhichao.gao@intel.com> <20190315051749.6564-18-zhichao.gao@intel.com> <46E887C8-DAAB-4855-BB70-69066F6B45FD@apple.com> To: "Gao, Liming" , Andrew Fish , Andrew Fish via edk2-devel , Mike Kinney , Zhichao Gao Cc: Hao Wu , edk2-devel , Bret Barkelew , Michael Turner , Star Zeng , Ard Biesheuvel , Laszlo Ersek From: Jordan Justen Message-ID: <155409943250.23072.1800190734018760556@jljusten-skl> User-Agent: alot/0.8 Date: Sun, 31 Mar 2019 23:17:12 -0700 Subject: Re: [PATCH V2 17/17] MdeModulePkg: Add PEIM and lib to dsc file X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 06:17:14 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2019-03-14 22:54:24, Andrew Fish via edk2-devel wrote: > I understand the motivation for this change as I've done something > much less portable that looks a lot like this to save the PEI XIP > space.... >=20 > I seem to remember a long time ago we add a public VA_LIST to an API > and we ran into an issue due to the marker format being compiler > specific. You don't tend to see this on VC++ as it mostly uses a > pointer to the frame, but GCC and clang can use a data structure > especially not on IA32 (i386) for a VA_LIST (this is part of the > reason there are so many #ifdefs in the Base.h VA_LIST section). >=20 > In the past to fix this Mike Kinney added BASE_LIST. I seem to > remember MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode passes > a BASE_LIST into ReportStatusCode vs. a VA_LIST for this reason. Was > this VA_LIST portability concern taken into consideration for this > new API? >=20 > In general VA_LIST is not an issue as long as all the code is > compiled with the same compiler but if binaries are in play then you > can have issues. So things like FSB, Option ROMs, OS Loaders, EFI > Shell, EFI Apps. are when you can see the issue. >=20 I didn't see a reply to Andrew's concern. Was it considered, and addressed? I remember having several issues in the past with var-args. I haven't seen it show up in quite a while. I know we have to make sure to consistently apply EFIAPI to such function declarations. I did think we still considered it forbidden to use var-args across a binary interface. (PPI, Protocol, Core functions) I'm not sure if EFIAPI is enough to make it safe as long as all code is compiled by the same compiler, or if it truely makes it safe for a binary compiled with one compiler to be called from a binary compiled with any other compiler. I'll add Ard and Laszlo to the Cc, as I seem to recall they may have looked at it before. (Although, I think they've been Cc'd on the series, so maybe they've already considered this, and don't expect there is a problem.) -Jordan