public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Rebecca Cran <rebecca@bluestop.org>
Cc: "Gao, Liming" <liming.gao@intel.com>,
	"Zhu, Yonghong" <yonghong.zhu@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	edk2-devel@ml01.01.org, Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5
Date: Wed, 22 Feb 2017 00:59:52 +0100	[thread overview]
Message-ID: <e495a632-35ef-1ebe-9dbf-7f7434368c01@redhat.com> (raw)
In-Reply-To: <148771713761.11536.11405248826433236318@jljusten-ivb>

On 02/21/17 23:45, Jordan Justen wrote:
> 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=ms ?
>>
> 
> Originally GCC didn't support -mabi=ms. 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=ms is that we are able to catch some
> cases of misused EFIAPI

I agree.

> 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=ms for DEBUG builds.

I agree (also for NOOPT builds).

> But, I think it would
> be good to get the size advantages of -mabi=ms by enabling it for
> RELEASE builds.

That sounds useful too (even though it wouldn't make the current problem go away).

As one caveat, I believe -mabi=ms wouldn't be allowed for building OpensslLib even for RELEASE. See "-DNO_MSABI_VA_FUNCS" in "OpensslLib.inf":

commit b2dc04a87fab89307240dc0f30b9a23bb5726c81
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sun Jul 17 11:57:45 2016 +0200

    CryptoPkg: set new define to avoid MS ABI VA_LIST on GCC/X64
    
    Set the #define NO_MSABI_VA_FUNCS that will be introduced in a subsequent
    patch to avoid the use of the MS ABI in variadic functions. In EDK2, such
    functions normally require the EFIAPI modifier to be used, but for external
    libraries such as OpenSSL, which lack these annotations, it is easier to
    simply revert to the default SysV style VA_LIST ABI.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
    Tested-by: Laszlo Ersek <lersek@redhat.com>
    Tested-By: Liming Gao <liming.gao@intel.com>
    Reviewed-by: Liming Gao <liming.gao@intel.com>

Thanks!
Laszlo



  reply	other threads:[~2017-02-21 23:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 15:28 [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5 Anthony PERARD
2016-12-01 15:28 ` [PATCH 1/4] OvmfPkg/XenHypercallLib: Add EFIAPI Anthony PERARD
2016-12-01 15:28 ` [PATCH 2/4] OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify Anthony PERARD
2016-12-01 15:28 ` [PATCH 3/4] OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions Anthony PERARD
2016-12-01 15:28 ` [PATCH 4/4] OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant, End}Access Anthony PERARD
2016-12-01 18:43 ` [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5 Laszlo Ersek
2016-12-01 20:06   ` Jordan Justen
2016-12-01 20:54     ` Laszlo Ersek
2016-12-02  0:58       ` Jordan Justen
2016-12-02  9:45         ` Laszlo Ersek
2016-12-02  4:36   ` Gao, Liming
2016-12-02 10:00     ` Laszlo Ersek
2016-12-02 16:02   ` Anthony PERARD
2016-12-02 19:26     ` Laszlo Ersek
2016-12-03 17:59       ` Laszlo Ersek
2016-12-05  2:55         ` Gao, Liming
2016-12-05 10:09           ` Laszlo Ersek
2017-02-21 16:39         ` Anthony PERARD
2017-02-21 17:07           ` Laszlo Ersek
2017-02-21 17:53             ` Anthony PERARD
2017-02-21 19:02               ` Laszlo Ersek
2017-02-21 19:08                 ` Rebecca Cran
2017-02-21 22:45                   ` Jordan Justen
2017-02-21 23:59                     ` Laszlo Ersek [this message]
2017-02-22 14:16                       ` Gao, Liming
2017-02-22  8:54                 ` Gao, Liming
2017-02-23 10:19                   ` Laszlo Ersek
2017-02-23 12:43                     ` Anthony PERARD
2017-02-23 13:00                     ` Gao, Liming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e495a632-35ef-1ebe-9dbf-7f7434368c01@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox