From: "Ard Biesheuvel" <ardb@kernel.org>
To: devel@edk2.groups.io, quic_llindhol@quicinc.com
Cc: Gerd Hoffmann <kraxel@redhat.com>,
rebecca@bsdio.com, Pedro Falcato <pedro.falcato@gmail.com>,
gaoliming <gaoliming@byosoft.com.cn>,
Oliver Smith-Denny <osd@smith-denny.com>,
Guomin Jiang <guomin.jiang@intel.com>,
Xiaoyu Lu <xiaoyu1.lu@intel.com>,
Jian J Wang <jian.j.wang@intel.com>,
Jiewen Yao <jiewen.yao@intel.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jordan Justen <jordan.l.justen@intel.com>,
Bob Feng <bob.c.feng@intel.com>, Andrew Fish <afish@apple.com>,
Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: 回复: [edk2-devel] [PATCH v2 00/13] BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49, rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC
Date: Mon, 3 Apr 2023 15:04:47 +0200 [thread overview]
Message-ID: <CAMj1kXHS3WuL2nVbKB4mq=L69eqOtEzVmeRvs7fG-OLw4hx6qw@mail.gmail.com> (raw)
In-Reply-To: <ZCrDXRLhu8p7xqDM@qc-i7.hemma.eciton.net>
On Mon, 3 Apr 2023 at 14:15, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
>
> On Mon, Apr 03, 2023 at 13:55:19 +0200, Ard Biesheuvel wrote:
> > I agree that we should either support a toolchain (and have CI
> > coverage for it) or not, in which case we should just remove it.
> >
> > However, the issues being reported are specific to SEV-SNP and TDX,
> > which implies that they are specific to OVMF. And actually, the
> > reported issue at
> >
> > OvmfPkg/Library/CcExitLib/CcExitVcHandler.c:1358:10:
> > error: ‘XCr0’ may be used uninitialized [-Werror=maybe-uninitialized]
> >
> > seems to be a valid concern.
> >
> > So the point I am making is that OVMF gets a lot of attention in the
> > open source project, but in the wider ecosystem, there are many
> > platforms relying on this code base that don't incorporate the Coco
> > components at all, so whether OVMF currently builds with GCC49 is not
> > 100% relevant.
> >
> > So I am leaning towards retaining GCC49 as GCCNOLTO, and getting some
> > coverage for it in CI, as we occasionally get useful diagnostics out
> > of it. But I am not going to fight any battles over it - I rarely use
> > it myself, and so I will not miss it when it's gone.
>
> I agree with all aspects of this statement. I would *prefer* to keep
> it as a canary - with CI.
>
Cheers.
And interestingly, GCC49 appears to spot an issue introduced with commit
commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8
Author: Hua Ma <hua.ma@intel.com>
Date: Mon Oct 11 11:43:12 2021 +0800
MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleList
where we may end up dereferencing a bogus 'Prot' pointer:
MdeModulePkg/Core/Dxe/Hand/Handle.c:1198:24:
error: ‘Prot’ may be used uninitialized [-Werror=maybe-uninitialized]
1198 | *Interface = Prot->Interface;
| ~~~~^~~~~~~~~~~
MdeModulePkg/Core/Dxe/Hand/Handle.c:994:24:
note: ‘Prot’ was declared here
994 | PROTOCOL_INTERFACE *Prot;
So I am going to change my mind, and state that I do care about GCC
non-LTO builds, as we have been introducing bugs into our code that we
could have spotted if anyone had bothered to test with this toolchain
config.
next prev parent reply other threads:[~2023-04-03 13:05 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 17:30 [PATCH v2 00/13] BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49, rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC Rebecca Cran
2023-03-28 17:30 ` [PATCH v2 01/13] OvmfPkg: Replace static struct initialization with ZeroMem call Rebecca Cran
2023-03-28 22:40 ` Yao, Jiewen
2023-03-28 22:45 ` Michael D Kinney
2023-03-28 17:31 ` [PATCH v2 02/13] CryptoPkg: Add CLANGDWARF and remove CLANG35 and CLANG38 compiler flags Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 03/13] BaseTools: Update CLANGDWARF toolchain and remove CLANG35 and CLANG38 Rebecca Cran
2023-03-29 3:46 ` [edk2-devel] " Guo, Gua
[not found] ` <1750C725F99FA0C2.29160@groups.io>
2023-03-29 9:24 ` Guo, Gua
2023-03-28 17:31 ` [PATCH v2 04/13] BaseTools: Remove VS2008, 2010, 2012 and 2013 toolchain definitions Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 05/13] BaseTools: Remove VS2008-VS2013 remnants Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 06/13] MdePkg: " Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 07/13] edksetup.bat: " Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 08/13] BaseTools: Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS defs Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 09/13] BaseTools: Remove EBC (EFI Byte Code) compiler definitions Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 10/13] OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for CLANGDWARF Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 11/13] Delete GCC48 and GCC49 toolchains and rename GCC5 to GCC Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 12/13] BaseTools: Remove unused CYGWIN_ defines from tools_def.txt.template Rebecca Cran
2023-03-28 17:31 ` [PATCH v2 13/13] Bump tools_def.txt VERSION to 3.0 Rebecca Cran
2023-03-28 17:57 ` [PATCH v2 00/13] BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49, rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC Ard Biesheuvel
2023-03-28 18:01 ` Rebecca Cran
2023-03-28 18:12 ` [edk2-devel] " Ard Biesheuvel
2023-03-29 10:21 ` Rebecca Cran
2023-03-29 10:30 ` Ard Biesheuvel
2023-03-29 1:19 ` 回复: " gaoliming
2023-03-29 7:39 ` Ard Biesheuvel
2023-03-29 10:20 ` Rebecca Cran
2023-03-29 11:28 ` Leif Lindholm
2023-03-29 11:53 ` Ard Biesheuvel
2023-04-02 15:41 ` 回复: " Rebecca Cran
2023-04-02 16:36 ` Ard Biesheuvel
2023-04-02 16:42 ` Michael D Kinney
2023-04-02 18:38 ` Pedro Falcato
2023-04-02 21:50 ` Rebecca Cran
2023-04-03 11:30 ` Gerd Hoffmann
2023-04-03 11:33 ` Rebecca Cran
2023-04-03 11:39 ` Gerd Hoffmann
2023-04-03 11:55 ` Ard Biesheuvel
2023-04-03 12:15 ` Leif Lindholm
2023-04-03 12:26 ` Rebecca Cran
2023-04-03 13:44 ` Pedro Falcato
2023-04-03 13:54 ` Rebecca Cran
2023-04-03 14:08 ` Gerd Hoffmann
2023-04-03 14:27 ` Rebecca Cran
2023-04-03 19:42 ` Michael D Kinney
2023-04-03 19:54 ` Rebecca Cran
2023-04-03 20:23 ` Michael D Kinney
2023-04-03 13:04 ` Ard Biesheuvel [this message]
2023-04-03 13:27 ` Michael D Kinney
2023-04-03 13:43 ` Ard Biesheuvel
2023-04-04 1:31 ` 回复: " gaoliming
2023-04-04 15:49 ` Rebecca Cran
2023-04-04 15:57 ` Pedro Falcato
2023-04-04 16:32 ` Leif Lindholm
2023-04-04 17:00 ` Rebecca Cran
2023-04-04 17:45 ` Michael D Kinney
2023-04-04 17:48 ` Rebecca Cran
2023-04-04 17:52 ` Michael D Kinney
2023-04-04 17:57 ` Pedro Falcato
2023-04-04 18:03 ` Rebecca Cran
2023-04-04 18:26 ` Ard Biesheuvel
2023-04-04 18:29 ` Michael D Kinney
2023-04-04 18:36 ` Rebecca Cran
2023-04-05 10:21 ` Ard Biesheuvel
2023-04-06 0:57 ` 回复: " gaoliming
2023-04-06 2:49 ` Rebecca Cran
2023-04-06 7:32 ` Ard Biesheuvel
2023-04-06 9:19 ` Marcin Juszkiewicz
2023-03-29 12:20 ` Ard Biesheuvel
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='CAMj1kXHS3WuL2nVbKB4mq=L69eqOtEzVmeRvs7fG-OLw4hx6qw@mail.gmail.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