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
Some of the longer execution jobs can be easily broken up into smaller pieces. 20 min may be a more realistic goal no matter how many agents are available. But would still require a lot of effort to implement caches and rebalance and tune. Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Rebecca Cran > Sent: Monday, April 3, 2023 12:55 PM > To: Kinney, Michael D ; devel@edk2.groups.io; > Gerd Hoffmann > Cc: Leif Lindholm ; Ard Biesheuvel > ; Pedro Falcato ; > Gao, Liming ; Oliver Smith-Denny > ; Jiang, Guomin ; > Lu, Xiaoyu1 ; Wang, Jian J ; > Yao, Jiewen ; Ard > Biesheuvel ; Justen, Jordan L > ; Feng, Bob C ; > Andrew Fish > 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 > > I wonder if it might be possible to get the total time to be under 10 > minutes by adding more agents? > > > -- > > Rebecca Cran > > > On 4/3/23 1:42 PM, Kinney, Michael D wrote: > > Rebecca, > > > > I have a test PR running that splits up CodeQL analysis > > and builds to attempt to balance the execution times. > > > > https://github.com/tianocore/edk2/pull/4233 > > > > GitHub Actions CodeQL: > > * Max job time ~21 minutes > > * Total Action Time ~31 minutes > > Azure Pipelines Builds: > > * Max job time ~32 minutes > > * Total job time ~36 minutes > > > > This is a reduction of about 6 minutes from other PRs > > in recent history, so may be worth checkin in. > > > > There is also a dependency on the total number of agents. > > If we have more jobs than agents, them they get queued > > up and will not run until another job completes. > > > > Mike > > > > > >> -Original Message- > >> From: devel@edk2.groups.io On Behalf Of Rebecca Cran > >> Sent: Monday, April 3, 2023 7:28 AM > >> To: Gerd Hoffmann > >> Cc: Leif Lindholm ; Ard Biesheuvel > >> ; devel@edk2.groups.io; Pedro Falcato > >> ; Gao, Liming ; Oliver > >> Smith-Denny ; Jiang, > Guomin > >> ; Lu, Xiaoyu1 ; Wang, Jian J > >> ; Yao, Jiewen > >> ; Ard Biesheuvel ; > >> Justen, Jordan L ; Feng, > >> Bob C ; Andrew Fish ; Kinney, > >> Michael D > >> 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 > >> > >> On 4/3/23 8:08 AM, Gerd Hoffmann wrote: > >>> So you want gcc-6 specifically or just an older version instead of > >>> latest? I could try add a RHEL-8 container (which ships gcc-8). > >> I'd want the oldest version that we support, so we know when we add > >> incompatible code. > >> > >> From Pedro's reply, it sounds like that'll be gcc 5 once we add > >> -std=c++11 to tools_def.txt.template. > >> > >> > >>> Well, I've wondered whenever it makes sense to do _less_ stuff in > >>> parallel, to get down the constant overhead (clone repos etc). > >>> Especially with a limit on parallel jobs that could be faster > >>> in the end ... > >> Maybe a combination? For example one task that I think could do with > >> being split up to run in parallel is the following: > >> > >> stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t > >> DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 > >> > >> (from > >> https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605=logs=c0929384-5a08-5c0f-b36d- > >> 6f51b6b81732=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) > >> > >> > >> It shows two tasks taking 13 minutes each. > >> > >> > >> -- > >> > >> Rebecca Cran > >> > >> > >> > >> > >> > >> > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102439): https://edk2.groups.io/g/devel/message/102439 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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
I wonder if it might be possible to get the total time to be under 10 minutes by adding more agents? -- Rebecca Cran On 4/3/23 1:42 PM, Kinney, Michael D wrote: Rebecca, I have a test PR running that splits up CodeQL analysis and builds to attempt to balance the execution times. https://github.com/tianocore/edk2/pull/4233 GitHub Actions CodeQL: * Max job time ~21 minutes * Total Action Time ~31 minutes Azure Pipelines Builds: * Max job time ~32 minutes * Total job time ~36 minutes This is a reduction of about 6 minutes from other PRs in recent history, so may be worth checkin in. There is also a dependency on the total number of agents. If we have more jobs than agents, them they get queued up and will not run until another job completes. Mike -Original Message- From: devel@edk2.groups.io On Behalf Of Rebecca Cran Sent: Monday, April 3, 2023 7:28 AM To: Gerd Hoffmann Cc: Leif Lindholm ; Ard Biesheuvel ; devel@edk2.groups.io; Pedro Falcato ; Gao, Liming ; Oliver Smith-Denny ; Jiang, Guomin ; Lu, Xiaoyu1 ; Wang, Jian J ; Yao, Jiewen ; Ard Biesheuvel ; Justen, Jordan L ; Feng, Bob C ; Andrew Fish ; Kinney, Michael D 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 On 4/3/23 8:08 AM, Gerd Hoffmann wrote: So you want gcc-6 specifically or just an older version instead of latest? I could try add a RHEL-8 container (which ships gcc-8). I'd want the oldest version that we support, so we know when we add incompatible code. From Pedro's reply, it sounds like that'll be gcc 5 once we add -std=c++11 to tools_def.txt.template. Well, I've wondered whenever it makes sense to do _less_ stuff in parallel, to get down the constant overhead (clone repos etc). Especially with a limit on parallel jobs that could be faster in the end ... Maybe a combination? For example one task that I think could do with being split up to run in parallel is the following: stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 (from https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605=logs=c0929384-5a08-5c0f-b36d- 6f51b6b81732=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) It shows two tasks taking 13 minutes each. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102438): https://edk2.groups.io/g/devel/message/102438 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] -=-=-=-=-=-=-=-=-=-=-=-
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
Rebecca, I have a test PR running that splits up CodeQL analysis and builds to attempt to balance the execution times. https://github.com/tianocore/edk2/pull/4233 GitHub Actions CodeQL: * Max job time ~21 minutes * Total Action Time ~31 minutes Azure Pipelines Builds: * Max job time ~32 minutes * Total job time ~36 minutes This is a reduction of about 6 minutes from other PRs in recent history, so may be worth checkin in. There is also a dependency on the total number of agents. If we have more jobs than agents, them they get queued up and will not run until another job completes. Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Rebecca Cran > Sent: Monday, April 3, 2023 7:28 AM > To: Gerd Hoffmann > Cc: Leif Lindholm ; Ard Biesheuvel > ; devel@edk2.groups.io; Pedro Falcato > ; Gao, Liming ; Oliver > Smith-Denny ; Jiang, Guomin > ; Lu, Xiaoyu1 ; Wang, Jian J > ; Yao, Jiewen > ; Ard Biesheuvel ; Justen, > Jordan L ; Feng, > Bob C ; Andrew Fish ; Kinney, Michael > D > 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 > > On 4/3/23 8:08 AM, Gerd Hoffmann wrote: > > So you want gcc-6 specifically or just an older version instead of > > latest? I could try add a RHEL-8 container (which ships gcc-8). > > I'd want the oldest version that we support, so we know when we add > incompatible code. > > From Pedro's reply, it sounds like that'll be gcc 5 once we add > -std=c++11 to tools_def.txt.template. > > > > Well, I've wondered whenever it makes sense to do _less_ stuff in > > parallel, to get down the constant overhead (clone repos etc). > > Especially with a limit on parallel jobs that could be faster > > in the end ... > > Maybe a combination? For example one task that I think could do with > being split up to run in parallel is the following: > > stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t > DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 > > (from > https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605=logs=c0929384-5a08-5c0f-b36d- > 6f51b6b81732=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) > > > It shows two tasks taking 13 minutes each. > > > -- > > Rebecca Cran > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102437): https://edk2.groups.io/g/devel/message/102437 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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
On 4/3/23 8:08 AM, Gerd Hoffmann wrote: So you want gcc-6 specifically or just an older version instead of latest? I could try add a RHEL-8 container (which ships gcc-8). I'd want the oldest version that we support, so we know when we add incompatible code. From Pedro's reply, it sounds like that'll be gcc 5 once we add -std=c++11 to tools_def.txt.template. Well, I've wondered whenever it makes sense to do _less_ stuff in parallel, to get down the constant overhead (clone repos etc). Especially with a limit on parallel jobs that could be faster in the end ... Maybe a combination? For example one task that I think could do with being split up to run in parallel is the following: stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 (from https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605=logs=c0929384-5a08-5c0f-b36d-6f51b6b81732=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) It shows two tasks taking 13 minutes each. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102404): https://edk2.groups.io/g/devel/message/102404 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] -=-=-=-=-=-=-=-=-=-=-=-
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
> 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. So you want gcc-6 specifically or just an older version instead of latest? I could try add a RHEL-8 container (which ships gcc-8). > Similarly, we should also add CLANGPDB and CLANGDWARF builds. Fedora ships clang + llvm (version 15.0.7 right now), so adding that to the CI container should be easy. > 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. Well, I've wondered whenever it makes sense to do _less_ stuff in parallel, to get down the constant overhead (clone repos etc). Especially with a limit on parallel jobs that could be faster in the end ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102402): https://edk2.groups.io/g/devel/message/102402 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On 4/3/23 7:44 AM, Pedro Falcato wrote:
On Mon, Apr 3, 2023 at 1:27 PM Rebecca Cran wrote:
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.
FYI, GCC 5 supports nullptr and the whole of C++11. I think the
problem is that the .inf doesn't force C++11 through -std={gnu,
c}++11, which makes gcc 5 use its default C++ standard.
Which, IIRC, was C++98 until gcc 6 or 7 (and 98 does not have nullptr).
Ah, thanks! We _do_ need to start specifying which C and C++ standards
we're building against, since relying on defaults gets us into problems
like this.
--
Rebecca Cran
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102401): https://edk2.groups.io/g/devel/message/102401
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]
-=-=-=-=-=-=-=-=-=-=-=-
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
On Mon, Apr 3, 2023 at 1:27 PM Rebecca Cran wrote:
>
> 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.
FYI, GCC 5 supports nullptr and the whole of C++11. I think the
problem is that the .inf doesn't force C++11 through -std={gnu,
c}++11, which makes gcc 5 use its default C++ standard.
Which, IIRC, was C++98 until gcc 6 or 7 (and 98 does not have nullptr).
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102400): https://edk2.groups.io/g/devel/message/102400
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]
-=-=-=-=-=-=-=-=-=-=-=-
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
On Mon, 3 Apr 2023 at 15:27, Kinney, Michael D wrote: > > Are the same issue(s) found with GCC5 with -b NOOPT? > None of these are found with NOOPT. Without the optimizer, GCC doesn't perform the analysis that is needed to figure out which variables are live (and valid) at which time, so it is not able to emit these diagnostics either. Note that the LTO compiler is not necessarily wrong here: it can generally see through all the function calls in a function, and so perhaps the state that the non-LTO compiler warns about is not actually reachable in the particular combination of components and libraries. However, relying on the LTO optimizer for this is fragile, and I'd much prefer having robust code that has additional checks for such states. By the same token, the LTO compiler will get rid of those if they are redundant and not needed for the program's correctness. > > > -Original Message- > > From: devel@edk2.groups.io On Behalf Of Ard > > Biesheuvel > > Sent: Monday, April 3, 2023 6:05 AM > > To: devel@edk2.groups.io; quic_llind...@quicinc.com > > Cc: Gerd Hoffmann ; rebe...@bsdio.com; Pedro Falcato > > ; Gao, Liming > > ; Oliver Smith-Denny ; > > Jiang, Guomin ; Lu, Xiaoyu1 > > ; Wang, Jian J ; Yao, Jiewen > > ; Ard Biesheuvel > > ; Justen, Jordan L ; > > Feng, Bob C ; Andrew Fish > > ; Kinney, Michael D > > 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 > > > > On Mon, 3 Apr 2023 at 14:15, 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. > > > > > > > Cheers. > > > > And interestingly, GCC49 appears to spot an issue introduced with commit > > > > commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8 > > Author: Hua Ma > > 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. > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102399): https://edk2.groups.io/g/devel/message/102399 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] -=-=-=-=-=-=-=-=-=-=-=-
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
Are the same issue(s) found with GCC5 with -b NOOPT? Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Ard Biesheuvel > Sent: Monday, April 3, 2023 6:05 AM > To: devel@edk2.groups.io; quic_llind...@quicinc.com > Cc: Gerd Hoffmann ; rebe...@bsdio.com; Pedro Falcato > ; Gao, Liming > ; Oliver Smith-Denny ; Jiang, > Guomin ; Lu, Xiaoyu1 > ; Wang, Jian J ; Yao, Jiewen > ; Ard Biesheuvel > ; Justen, Jordan L ; > Feng, Bob C ; Andrew Fish > ; Kinney, Michael D > 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 > > On Mon, 3 Apr 2023 at 14:15, 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. > > > > Cheers. > > And interestingly, GCC49 appears to spot an issue introduced with commit > > commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8 > Author: Hua Ma > 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. > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102398): https://edk2.groups.io/g/devel/message/102398 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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
On Mon, 3 Apr 2023 at 14:15, 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. > Cheers. And interestingly, GCC49 appears to spot an issue introduced with commit commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8 Author: Hua Ma 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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102397): https://edk2.groups.io/g/devel/message/102397 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] -=-=-=-=-=-=-=-=-=-=-=-
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
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] -=-=-=-=-=-=-=-=-=-=-=-
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
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. / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102395): https://edk2.groups.io/g/devel/message/102395 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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
On Mon, 3 Apr 2023 at 13:39, Gerd Hoffmann wrote: > > On Mon, Apr 03, 2023 at 05:33:10AM -0600, Rebecca Cran wrote: > > On 4/3/23 5:30 AM, Gerd Hoffmann wrote: > > > I'm wondering what the point in keeping a known-broken toolchain though. > > > It is apparently unused when nobody noticed the breakage ... > > > > I agree. At this point I want to reach a consensus and get this patch series > > committed, even if that means leaving a known broken toolchain around. > > Sure. That question was meant more for gaoliming who expressed interest > in keeping it. gaoliming? > > I'd prefer to keep GCC only. In case we decide to keep both LTO and > non-LTO variants the GCC + GCCNOLTE naming scheme looks fine to me. > 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. Liming, are you aware of any users relying on non-LTO GCC codegen for any reason? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102393): https://edk2.groups.io/g/devel/message/102393 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On Mon, Apr 03, 2023 at 05:33:10AM -0600, Rebecca Cran wrote: > On 4/3/23 5:30 AM, Gerd Hoffmann wrote: > > I'm wondering what the point in keeping a known-broken toolchain though. > > It is apparently unused when nobody noticed the breakage ... > > I agree. At this point I want to reach a consensus and get this patch series > committed, even if that means leaving a known broken toolchain around. Sure. That question was meant more for gaoliming who expressed interest in keeping it. gaoliming? I'd prefer to keep GCC only. In case we decide to keep both LTO and non-LTO variants the GCC + GCCNOLTE naming scheme looks fine to me. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102392): https://edk2.groups.io/g/devel/message/102392 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On 4/3/23 5:30 AM, Gerd Hoffmann wrote: I'm wondering what the point in keeping a known-broken toolchain though. It is apparently unused when nobody noticed the breakage ... I agree. At this point I want to reach a consensus and get this patch series committed, even if that means leaving a known broken toolchain around. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102391): https://edk2.groups.io/g/devel/message/102391 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On Sun, Apr 02, 2023 at 03:50:33PM -0600, Rebecca Cran wrote: > On 4/2/23 12:38 PM, Pedro Falcato wrote: > > As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would > > rather keep GCC5 as GCC5, for the next future iteration of "lets bump > > a new toolchain because we need feature X". > > Given we've gone from GCC 5 through 12 with no new toolchains, I'd prefer to > just have GCC. > > > This is unsurprising, plenty of NOLTO build breakage. Since no one > > seems to use this, could we think about axing this or? > > > > Just seems silly to have an extra toolchain (with extra cognitive > > overhead for anyone looking at tools_def) for s/-flto//g > > Since Liming wants to keep it, let's make all the other changes (deleting VS > 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and GCC for now. If > nobody fixes the problems with GCCNOLTO, maybe we can revisit dropping it in > a few months? I'm wondering what the point in keeping a known-broken toolchain though. It is apparently unused when nobody noticed the breakage ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102390): https://edk2.groups.io/g/devel/message/102390 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On 4/2/23 12:38 PM, Pedro Falcato wrote: As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would rather keep GCC5 as GCC5, for the next future iteration of "lets bump a new toolchain because we need feature X". Given we've gone from GCC 5 through 12 with no new toolchains, I'd prefer to just have GCC. This is unsurprising, plenty of NOLTO build breakage. Since no one seems to use this, could we think about axing this or? Just seems silly to have an extra toolchain (with extra cognitive overhead for anyone looking at tools_def) for s/-flto//g Since Liming wants to keep it, let's make all the other changes (deleting VS 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and GCC for now. If nobody fixes the problems with GCCNOLTO, maybe we can revisit dropping it in a few months? -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102366): https://edk2.groups.io/g/devel/message/102366 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On Sun, Apr 2, 2023 at 4:41 PM Rebecca Cran wrote: > > On 3/28/23 7:19 PM, gaoliming wrote: > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC > > tool chain with LTO enable option. > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and > > also keep their name as is. > > Is anything still _using_ GCC49 though? Since I strongly suspect nobody > is using gcc 4.9, I'll rename it to GCCNOLTO. As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would rather keep GCC5 as GCC5, for the next future iteration of "lets bump a new toolchain because we need feature X". > > When I try and build OVMF with it, I get the following error: > > > /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: > In function ‘InternalSetPageState’: > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: > error: ‘Cmd’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] >166 | Info->Entry[i].CurrentPage = 0; >| ^~~ > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: > note: ‘Cmd’ was declared here > 32 | UINTN Cmd; >| ^~~ > rm -f > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > "ar" cr > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.lst > cc1: all warnings being treated as errors > make: *** [GNUmakefile:304: > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/X64/SnpPageStateChangeInternal.obj] > Error 1 This is unsurprising, plenty of NOLTO build breakage. Since no one seems to use this, could we think about axing this or? Just seems silly to have an extra toolchain (with extra cognitive overhead for anyone looking at tools_def) for s/-flto//g -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102365): https://edk2.groups.io/g/devel/message/102365 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] -=-=-=-=-=-=-=-=-=-=-=-
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
NOOPT builds can be very valuable to find these types of issues. Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Ard Biesheuvel > Sent: Sunday, April 2, 2023 9:37 AM > To: Rebecca Cran > Cc: Gao, Liming ; devel@edk2.groups.io; Oliver > Smith-Denny ; Jiang, Guomin > ; Lu, Xiaoyu1 ; Wang, Jian J > ; Yao, Jiewen > ; Ard Biesheuvel ; Justen, > Jordan L ; Gerd > Hoffmann ; Feng, Bob C ; Andrew Fish > ; Leif Lindholm > ; Kinney, Michael D > 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 > > On Sun, 2 Apr 2023 at 17:41, Rebecca Cran wrote: > > > > On 3/28/23 7:19 PM, gaoliming wrote: > > > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another > > > GCC tool chain with LTO enable option. > > > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and > > > also keep their name as is. > > > > Is anything still _using_ GCC49 though? Since I strongly suspect nobody > > is using gcc 4.9, I'll rename it to GCCNOLTO. > > > > When I try and build OVMF with it, I get the following error: > > > > > > /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: > > In function ‘InternalSetPageState’: > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: > > error: ‘Cmd’ may be used uninitialized in this function > > [-Werror=maybe-uninitialized] > >166 | Info->Entry[i].CurrentPage = 0; > >| ^~~ > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: > > note: ‘Cmd’ was declared here > > 32 | UINTN Cmd; > >| ^~~ > > rm -f > > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > > "ar" cr > > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > > > @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.ls > t > > cc1: all warnings being treated as errors > > make: *** [GNUmakefile:304: > > > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/ > X64/SnpPageStateChangeInternal.obj] > > Error 1 > > > > > > build.py... > > : error 7000: Failed to execute command > > make tbuild > > [/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib] > > > > > > build.py... > > : error F002: Failed to build module > > > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf > > [X64, GCC49, RELEASE] > > > > - Failed - > > Build end time: 09:38:34, Apr.02 2023 > > Build total time: 00:00:14 > > > > That warning seems reasonable to me: Cmd may be uninitialized, and > only under LTO do we get sufficient optimization and inlining for the > code generator to be able to infer that the 'default' case is > unreachable. > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102363): https://edk2.groups.io/g/devel/message/102363 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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
On Sun, 2 Apr 2023 at 17:41, Rebecca Cran wrote: > > On 3/28/23 7:19 PM, gaoliming wrote: > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC > > tool chain with LTO enable option. > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and > > also keep their name as is. > > Is anything still _using_ GCC49 though? Since I strongly suspect nobody > is using gcc 4.9, I'll rename it to GCCNOLTO. > > When I try and build OVMF with it, I get the following error: > > > /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: > In function ‘InternalSetPageState’: > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: > error: ‘Cmd’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] >166 | Info->Entry[i].CurrentPage = 0; >| ^~~ > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: > note: ‘Cmd’ was declared here > 32 | UINTN Cmd; >| ^~~ > rm -f > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > "ar" cr > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.lst > cc1: all warnings being treated as errors > make: *** [GNUmakefile:304: > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/X64/SnpPageStateChangeInternal.obj] > Error 1 > > > build.py... > : error 7000: Failed to execute command > make tbuild > [/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib] > > > build.py... > : error F002: Failed to build module > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf > [X64, GCC49, RELEASE] > > - Failed - > Build end time: 09:38:34, Apr.02 2023 > Build total time: 00:00:14 > That warning seems reasonable to me: Cmd may be uninitialized, and only under LTO do we get sufficient optimization and inlining for the code generator to be able to infer that the 'default' case is unreachable. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102362): https://edk2.groups.io/g/devel/message/102362 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] -=-=-=-=-=-=-=-=-=-=-=-
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
On 3/28/23 7:19 PM, gaoliming wrote: GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. Is anything still _using_ GCC49 though? Since I strongly suspect nobody is using gcc 4.9, I'll rename it to GCCNOLTO. When I try and build OVMF with it, I get the following error: /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: In function ‘InternalSetPageState’: /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: error: ‘Cmd’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 166 | Info->Entry[i].CurrentPage = 0; | ^~~ /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: note: ‘Cmd’ was declared here 32 | UINTN Cmd; | ^~~ rm -f /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib "ar" cr /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.lst cc1: all warnings being treated as errors make: *** [GNUmakefile:304: /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/X64/SnpPageStateChangeInternal.obj] Error 1 build.py... : error 7000: Failed to execute command make tbuild [/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib] build.py... : error F002: Failed to build module /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf [X64, GCC49, RELEASE] - Failed - Build end time: 09:38:34, Apr.02 2023 Build total time: 00:00:14 -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102361): https://edk2.groups.io/g/devel/message/102361 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] -=-=-=-=-=-=-=-=-=-=-=-
