public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Liming Gao" <liming.gao@intel.com>
To: Laszlo Ersek <lersek@redhat.com>, Andrew Fish <afish@apple.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain
Date: Wed, 9 Oct 2019 14:44:48 +0000	[thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E514EAB@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <6f49899d-b5e4-70ad-82e5-08c5a8649ac8@redhat.com>

Laszlo:

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, October 9, 2019 9:44 PM
> To: Andrew Fish <afish@apple.com>; devel@edk2.groups.io
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain
> 
> On 10/09/19 01:08, Andrew Fish wrote:
> 
> > So I guess the way to describe it is XCODE inherits GCC and only needs to override when it is different.
> 
> Thank you for the explanation!
> 
> I've been trying to figure out why this inheritance bothers me so much.
> I guess the reason is the following:
> 
> I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, GCC5).
> Assume that I realize that a gcc-specific change is needed to some part
> of the code. (It could be build options, or gcc specific source code,
> etc.) Then, I go to the gcc documentation, and verify whether the change
> is indeed supported by all the relevant gcc versions.
> 
> If the change is possible with only some gcc versions, then I likely
> write the change for a specific toolchain only, such as GCC5. Fine.
> 
> Now assume that my documentation review proves that *all* GCCxx
> toolchains, supported by edk2, should receive the update. This could be
> a #pragma, a command line flag, some __attribute__, etc. I'd very likely
> express the change for the whole GCC toolchain *family*, and not
> enumerate it for GCC48, GCC49, GCC5 individually.
> 
> And now I learn that said approach would be wrong, because such a change
> would be inherited by XCODExx and CLANGxx too (via FAMILY), fully
> against my intent, unless XCODExx and CLANGxx overrode the particular
> aspect (via BUILDRULEFAMILY).

The difference between XCODE/CLANG and GCCXX is the linker. Current patches are
introduced for the different linker. Clang supports most usage of GCC compiler.
So, CLANG and XCODE uses GCC family. When I enable XCODE or CLANG tool chain
in the platform, I don't find other incompatible behavior with GCC compiler.
So, I think it is safe to let CLANG inherit GCC option except for these two cases.
When you make new changes, and verify them with GCC compiler, that's enough.
You don't need to specially verify them with XCODE or CLANG. In most case, GCC 
compiler pass, XCODE or CLANG can also pass.

Thanks
Liming
> 
> This means that, after checking the gcc documentation meticulously
> (multiple releases), and possibly even testing multiple gcc
> installations, I could still regress edk2 (CLANGxx and/or XCODExx
> specific parts), because they could inherit my GCC-oriented changes that
> I never meant for CLANGxx and/or XCODExx.
> 
> I don't use XCODE or CLANG, I don't test on them, and now it seems I can
> restrict changes to the *actual* gcc compilers only if I keep spelling
> out the individual toolchain names, such as GCC48, GCC49, GCC5.
> 
> This makes the toolchain family concept totally useless to me (and to
> other users that only care about actual gcc compilers). There is no
> *family* facility available that allows people to restrict settings to
> actual gcc compilers. In other words, we can't express "all GCCxx
> toolchains, regardless of toolchain version, but not XCODE, and also not
> CLANG".
> 
> Thanks
> Laszlo

  reply	other threads:[~2019-10-09 14:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27  7:46 [Patch 00/12] New Cross OS tool chain CLANG9 Liming Gao
2019-09-27  7:46 ` [Patch 01/12] BaseTools tools_def.template: Remove unnecessary $(DEST_DIR_DEBUG) path Liming Gao
2019-09-27  7:46 ` [Patch 02/12] BaseTools tools_def: Add CLANG9 tool chain to directly generate PE image Liming Gao
2019-09-27 10:13   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-27  7:46 ` [Patch 03/12] BaseTools GenFw: Fix the issue to update the wrong size as SectionSize Liming Gao
2019-09-27 10:15   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-27  7:46 ` [Patch 04/12] MdePkg Base.h: Add definition for CLANG9 tool chain Liming Gao
2019-09-27  7:46 ` [Patch 05/12] MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO functions Liming Gao
2019-09-30 20:35   ` [edk2-devel] " Laszlo Ersek
2019-09-30 21:11     ` Andrew Fish
2019-10-08 14:47       ` Liming Gao
2019-10-08 20:22         ` Laszlo Ersek
2019-10-10 12:32           ` Liming Gao
2019-10-10 16:32             ` Laszlo Ersek
2019-10-11  1:28               ` Liming Gao
2019-10-11 19:22               ` Jordan Justen
2019-10-12  6:18                 ` Liming Gao
2019-09-27  7:46 ` [Patch 06/12] MdeModulePkg LzmaCustomDecompressLib: Update macro to be same in CLANG tool Liming Gao
2019-09-27  7:46 ` [Patch 07/12] MdeModulePkg RegularExpressionDxe: Disable warning for CLANG9 tool chain Liming Gao
2019-09-27  7:46 ` [Patch 08/12] CryptoPkg: Append options to make CLANG9 tool chain pass build Liming Gao
2019-09-27  7:46 ` [Patch 09/12] CryptoPkg IntrinsicLib: Make _fltused always be used Liming Gao
2019-09-27  8:34   ` [edk2-devel] " Yao, Jiewen
2019-09-29  6:32     ` Liming Gao
2019-09-27  7:46 ` [Patch 10/12] EmulatorPkg: Enable CLANG9 tool chain Liming Gao
2019-09-27  7:46 ` [Patch 11/12] OvmfPkg: " Liming Gao
2019-09-30 20:42   ` [edk2-devel] " Laszlo Ersek
2019-10-08 15:02     ` Liming Gao
2019-10-08 22:29       ` Laszlo Ersek
2019-10-08 23:08         ` Andrew Fish
2019-10-09 13:43           ` Laszlo Ersek
2019-10-09 14:44             ` Liming Gao [this message]
2019-10-09 16:22               ` [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain - Andrew Fish
2019-10-10  7:35                 ` Laszlo Ersek
2019-10-10 12:18                   ` Liming Gao
2019-10-10 16:29                     ` [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain Andrew Fish
2019-10-10 16:43                     ` [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain - Laszlo Ersek
2019-10-11  1:47                       ` Liming Gao
2019-10-11  9:57                         ` Laszlo Ersek
2019-10-11  9:37               ` [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain Laszlo Ersek
2019-10-12  8:22                 ` Liming Gao
2019-09-27  7:46 ` [Patch 12/12] OvmfPkg SecMain: Add build option "-fno-omit-frame-pointer" for CLANG9 X64 Liming Gao
2019-09-30 21:09   ` [edk2-devel] " Laszlo Ersek
2019-10-08 15:09     ` Liming Gao
     [not found]     ` <15CBB488DC5DB3E9.15045@groups.io>
2019-10-10 14:08       ` Liming Gao
2019-10-10 17:35         ` Laszlo Ersek
2019-10-11  1:30           ` Liming Gao
2019-10-11  9:48             ` Laszlo Ersek
2019-09-27  8:33 ` [edk2-devel] [Patch 00/12] New Cross OS tool chain CLANG9 Yao, Jiewen

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=4A89E2EF3DFEDB4C8BFDE51014F606A14E514EAB@SHSMSX104.ccr.corp.intel.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