From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 58631821CD for ; Tue, 21 Feb 2017 14:45:39 -0800 (PST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP; 21 Feb 2017 14:45:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,191,1484035200"; d="scan'208";a="228121373" Received: from ahirst-mobl.amr.corp.intel.com (HELO localhost) ([10.252.140.121]) by fmsmga004.fm.intel.com with ESMTP; 21 Feb 2017 14:45:38 -0800 MIME-Version: 1.0 To: Anthony PERARD , Laszlo Ersek , Rebecca Cran Message-ID: <148771713761.11536.11405248826433236318@jljusten-ivb> From: Jordan Justen In-Reply-To: <0d8b276a-c2ff-8797-4302-953febae931f@bluestop.org> Cc: "Gao, Liming" , "Zhu, Yonghong" , Ard Biesheuvel , edk2-devel@lists.01.org, Konrad Rzeszutek Wilk References: <20161201152819.8341-1-anthony.perard@citrix.com> <53c67cb5-e947-8979-7738-288cc83f374b@redhat.com> <20161202160201.GA1848@perard.uk.xensource.com> <9c0c9f43-a297-179f-2d57-fa5d8fab3763@redhat.com> <20170221163922.GC1867@perard.uk.xensource.com> <97214320-6054-8034-7667-6edde4debd80@redhat.com> <20170221175303.GD1867@perard.uk.xensource.com> <2a9ad7dd-fbeb-5a36-091f-d8592e95c509@redhat.com> <0d8b276a-c2ff-8797-4302-953febae931f@bluestop.org> User-Agent: alot/0.5.1 Date: Tue, 21 Feb 2017 14:45:37 -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: Tue, 21 Feb 2017 22:45:39 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-02-21 11:08:24, Rebecca Cran wrote: > On 2/21/2017 12:02 PM, Laszlo Ersek wrote: > = > > But in this case, the full edk2 codebase has to be grepped for > > VA_LIST-taking functions, and all of them must be flipped to EFIAPI, if > > they currently aren't EFIAPI. Covering just XenStoreVSPrint() seems > > incomplete. (Note: CryptoPkg/Library/OpensslLib is an exception.) > = > I think this was discussed previously but I can't remember: is there a = > reason for not just compiling everything with -mabi=3Dms ? > = Originally GCC didn't support -mabi=3Dms. Once it gained support, it then produced larger executables. Nowadays (and for quite some time), I think it generally results in smaller executables. A benefit of not using -mabi=3Dms is that we are able to catch some cases of misused EFIAPI with a compiler warning, or unfortunately in some cases with crashes or misbehaving code. I think the benefit of helping keep EFIAPI clean means that we should continue to not use -mabi=3Dms for DEBUG builds. But, I think it would be good to get the size advantages of -mabi=3Dms by enabling it for RELEASE builds. -Jordan