On 4/3/23 6:15 AM, Leif Lindholm 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.
Given it's catching issues, I'd like to keep it too.
In terms of CI coverage, I'd like to have both gcc 6 and gcc 12 running
GCC and GCCNOLTO builds: we've already broken gcc 5 compatibility by
introducing GoogleTest (which uses nullptr), so by doing builds with gcc
6 we'll be able to know when we break it and update
tools_def.txt.template with a note that we'll subsequently require gcc 7.
Similarly, we should also add CLANGPDB and CLANGDWARF builds.
I suspect we'll rapidly run into scaling issues though, since GitHub
Actions has a limit of 20 concurrent jobs on the free plan
(https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration),
and in order to keep CI times reasonable we'll probably want many more
tasks to be running in parallel. There's a beta 'larger runners' feature
(https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners),
but I'm wondering if we might want to scale using something like Azure
or EC2 (https://github.com/machulav/ec2-github-runner) instead, if the
costs aren't going to be prohibitive?
--
Rebecca Cran
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102396): https://edk2.groups.io/g/devel/message/102396
Mute This Topic: https://groups.io/mt/97919856/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
