Menu
▾
▴
edk2-buildtools-devel — EDK II Build Tools Developer discussions
You can subscribe to this list here.
| 2010 |
Jan
(1) |
Feb
(2) |
Mar
(12) |
Apr
(3) |
May
(2) |
Jun
(16) |
Jul
(24) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(8) |
Feb
(4) |
Mar
(6) |
Apr
(9) |
May
(4) |
Jun
(32) |
Jul
(14) |
Aug
|
Sep
(24) |
Oct
(26) |
Nov
(34) |
Dec
(15) |
| 2012 |
Jan
(16) |
Feb
(27) |
Mar
(44) |
Apr
(10) |
May
(8) |
Jun
(15) |
Jul
(10) |
Aug
(15) |
Sep
(12) |
Oct
(4) |
Nov
(3) |
Dec
(16) |
| 2013 |
Jan
(8) |
Feb
(4) |
Mar
(8) |
Apr
(7) |
May
(22) |
Jun
(17) |
Jul
(18) |
Aug
(31) |
Sep
(19) |
Oct
(16) |
Nov
(26) |
Dec
(11) |
| 2014 |
Jan
(21) |
Feb
(23) |
Mar
(17) |
Apr
(19) |
May
(39) |
Jun
(33) |
Jul
(86) |
Aug
(11) |
Sep
(5) |
Oct
(19) |
Nov
(1) |
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kandela, M. <mar...@in...> - 2014-06-27 15:37:26
|
Robert, Thank you very much for the hint. I was able to finally make a build after trying for so long. Basically, you have to exclude the build directory from the Anti-Virus' On-Access-Scan list. Thanks! -Marwan From: Fendt, Robert (GE Germany) [mailto:rob...@ge...] Sent: Friday, June 27, 2014 3:44 AM To: Kandela, Marwan; edk...@li... Cc: Johnson, Robert J Subject: RE: BIOS Build Problem Hi Marwan, I had a similar (sporadic) problem last year which came out of nowhere (no changes in Tools etc...). The solution was that Anti-Virus SW was locking some files and this resulted in the build error. Stopped the Virus-SW => build worked stable. Maybe this helps for you too... Best regards, Robert From: Kandela, Marwan [mailto:mar...@in...] Sent: Donnerstag, 26. Juni 2014 15:41 To: edk...@li...<mailto:edk...@li...> Cc: Johnson, Robert J Subject: [edk2-buildtools] BIOS Build Problem Hello, I have been having a problem making a BIOS build on my computer for the last 3 weeks. Someone suggested that I clear the Conf directory and retry, but that did not help. I also uninstalled all my build tool like Visual Studio and reinstalled them, but that did not help either. Can I please get some help with this? Thanks -Marwan Processing meta-data ....... build... : error C0DE: Unknown fatal error when processing [q:\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\DxeCoreMemoryAllocationLib.inf] (Please send email to edk...@li...<mailto:edk...@li...> for help, attaching following call stack trace!) (Python 2.5.4 on win32) Traceback (most recent call last): File "build.py", line 1824, in Main File "build.py", line 1589, in Launch File "build.py", line 1239, in _BuildPlatform File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 119, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 297, in _Init File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1271, in _GetPackageList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1365, in _GetLibraryAutoGenList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1352, in _GetAutoGenObjectList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 2835, in _GetLibraryAutoGenList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 2548, in _GetLibraryList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1431, in ApplyLibraryInstance File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\WorkspaceDatabase.py", line 2329, in __getitem__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 350, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 93, in __init__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 49, in __init__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaDataTable.py", line 65, in Create OperationalError: unable to open database file - Failed - Build end time: 09:24:16, Jun.26 2014 Build total time: 00:00:08 Enabled Nvar for XML CLI knobs = L"Setup" Conflicting Knob Names found & fixed in BiosKnobsVarstoreStringsNew.c file = 0 Xml Cli Knobs Name Validation was successfull! BiosKnobsVarstoreStrings.c File refreshed |
|
From: Fendt, R. (GE Germany) <rob...@ge...> - 2014-06-27 09:16:51
|
Hi Marwan, I had a similar (sporadic) problem last year which came out of nowhere (no changes in Tools etc...). The solution was that Anti-Virus SW was locking some files and this resulted in the build error. Stopped the Virus-SW => build worked stable. Maybe this helps for you too... Best regards, Robert From: Kandela, Marwan [mailto:mar...@in...] Sent: Donnerstag, 26. Juni 2014 15:41 To: edk...@li... Cc: Johnson, Robert J Subject: [edk2-buildtools] BIOS Build Problem Hello, I have been having a problem making a BIOS build on my computer for the last 3 weeks. Someone suggested that I clear the Conf directory and retry, but that did not help. I also uninstalled all my build tool like Visual Studio and reinstalled them, but that did not help either. Can I please get some help with this? Thanks -Marwan Processing meta-data ....... build... : error C0DE: Unknown fatal error when processing [q:\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\DxeCoreMemoryAllocationLib.inf] (Please send email to edk...@li...<mailto:edk...@li...> for help, attaching following call stack trace!) (Python 2.5.4 on win32) Traceback (most recent call last): File "build.py", line 1824, in Main File "build.py", line 1589, in Launch File "build.py", line 1239, in _BuildPlatform File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 119, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 297, in _Init File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1271, in _GetPackageList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1365, in _GetLibraryAutoGenList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1352, in _GetAutoGenObjectList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 2835, in _GetLibraryAutoGenList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 2548, in _GetLibraryList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1431, in ApplyLibraryInstance File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\WorkspaceDatabase.py", line 2329, in __getitem__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 350, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 93, in __init__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 49, in __init__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaDataTable.py", line 65, in Create OperationalError: unable to open database file - Failed - Build end time: 09:24:16, Jun.26 2014 Build total time: 00:00:08 Enabled Nvar for XML CLI knobs = L"Setup" Conflicting Knob Names found & fixed in BiosKnobsVarstoreStringsNew.c file = 0 Xml Cli Knobs Name Validation was successfull! BiosKnobsVarstoreStrings.c File refreshed |
|
From: Gao, L. <lim...@in...> - 2014-06-27 07:36:57
|
Andrew: If FvBaseAddress and FvForceRebase is not specified, only FV that is placed in FD will be rebased to its position in FD. If FvBaseAddress and FvForceRebase is specified, they will decide whether FV is rebased or rebased to where no matter this FV is a standalone or a part of FD. Thanks Liming -----Original Message----- From: Andrew Fish [mailto:af...@ap...] Sent: Friday, June 27, 2014 7:46 AM To: edk...@li... Cc: edk...@li... Subject: [edk2-buildtools] Do FvBaseAddress and FvForceRebase require the FV to be in an FD to work? It is a little unclear from the FDF spec if FvBaseAddress and FvForceRebase work in a stand alone [FV] section, or if they require an [FV] to be part of an FD to get relocated. What modes are supported? Thanks, Andrew Fish ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ edk2-buildtools-devel mailing list edk...@li... https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2014-06-26 23:46:17
|
It is a little unclear from the FDF spec if FvBaseAddress and FvForceRebase work in a stand alone [FV] section, or if they require an [FV] to be part of an FD to get relocated. What modes are supported? Thanks, Andrew Fish |
|
From: Kandela, M. <mar...@in...> - 2014-06-26 13:41:26
|
Hello, I have been having a problem making a BIOS build on my computer for the last 3 weeks. Someone suggested that I clear the Conf directory and retry, but that did not help. I also uninstalled all my build tool like Visual Studio and reinstalled them, but that did not help either. Can I please get some help with this? Thanks -Marwan Processing meta-data ....... build... : error C0DE: Unknown fatal error when processing [q:\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\DxeCoreMemoryAllocationLib.inf] (Please send email to edk...@li...<mailto:edk...@li...> for help, attaching following call stack trace!) (Python 2.5.4 on win32) Traceback (most recent call last): File "build.py", line 1824, in Main File "build.py", line 1589, in Launch File "build.py", line 1239, in _BuildPlatform File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 119, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 297, in _Init File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1271, in _GetPackageList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1365, in _GetLibraryAutoGenList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1352, in _GetAutoGenObjectList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 2835, in _GetLibraryAutoGenList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 2548, in _GetLibraryList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1431, in ApplyLibraryInstance File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\WorkspaceDatabase.py", line 2329, in __getitem__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 350, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 93, in __init__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaFileTable.py", line 49, in __init__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaDataTable.py", line 65, in Create OperationalError: unable to open database file - Failed - Build end time: 09:24:16, Jun.26 2014 Build total time: 00:00:08 Enabled Nvar for XML CLI knobs = L"Setup" Conflicting Knob Names found & fixed in BiosKnobsVarstoreStringsNew.c file = 0 Xml Cli Knobs Name Validation was successfull! BiosKnobsVarstoreStrings.c File refreshed |
|
From: Laszlo E. <le...@re...> - 2014-06-25 10:20:40
|
On 06/24/14 11:55, Paolo Bonzini wrote:
> As long as $EDK_TOOLS_PATH is properly set, the BaseTools/ directory
> is not necessary in the workspace. The BuildEnv file itself suggests
> setting the variable if BaseTools/ is not available.
>
> However, this only works if the user also sets $WORKSPACE. Otherwise,
> BuildEnv refuses to set WORKSPACE itself and does not even try to use
> the preset $EDK_TOOLS_PATH. Remove the check that fails, as it does
> not have any practical benefit.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini <pbo...@re...>
>
> --- a/BaseTools/BuildEnv
> +++ b/BaseTools/BuildEnv
> @@ -23,14 +23,6 @@
> return 0
> fi
>
> - if [ ! ${BASH_SOURCE[0]} -ef ./BaseTools/BuildEnv ]
> - then
> - echo Run this script from the base of your tree. For example:
> - echo " cd /Path/To/Edk/Root"
> - echo " . BaseTools/BuildEnv"
> - return 1
> - fi
> -
> #
> # Set $WORKSPACE
> #
>
Given Paolo's
[PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools
Reviewed-by: Laszlo Ersek <le...@re...>
|
|
From: Laszlo E. <le...@re...> - 2014-06-25 09:31:44
|
On 06/25/14 05:49, Jordan Justen wrote: > The git command 'git am' will take an email message (or git patch > attached to an email), and apply the patch along with the commit > message making it very easy for the patch submitter to send the patch > along with a good commit message, and also making it very easy for the > maintainer to incorporate that patch into the tree. Right. There's one quirk for edk2: since the project uses CRLF line terminators, one needs git config core.whitespace cr-at-eol git config am.keepcr true (The 2nd command is important for 'git am'.) > Laszlo, > > Your 0004 patch is Reviewed-by: Jordan Justen > <jor...@in...>, and committed. Thanks! > I think it is usually > better to use git send-email with patches, rather than attaching them > because they are more easy to notice and to code review. In the general case I agree (and I don't disagree in this case either). In an ongoing discussion, when I *reply* with patches, I'm torn between attaching the patches or just sending them with In-Reply-To. For example, AFAICT, qemu-devel doesn't like patches posted in-thread, so you're bound to lose either the threading or the plaintext patch posting. Also in the past I think I've experienced less abuse to (non-OvmfPkg, non-Arm*Pkg) commit messages on edk2-devel when patches were attached. I had no specific worry in this case, it was just a fuzzy feeling that attaching the patches would be safer for threading (albeit harder to notice / review). I'll mail them directly next time, with In-Reply-To. It's great that the commit message details have been discussed in advance this time! Thanks Laszlo |
|
From: Gao, L. <lim...@in...> - 2014-06-25 05:03:00
|
Got it.
I just commit BaseTools trunk change at 2670.
Thanks
Liming
-----Original Message-----
From: Jordan Justen [mailto:jlj...@gm...]
Sent: Wednesday, June 25, 2014 11:49 AM
To: Gao, Liming; Laszlo Ersek
Cc: Olivier Martin; edk...@li...; edk...@li...
Subject: Git patch commit messages - Re: [edk2-buildtools] [edk2] [Patch] Remove GCC option -Wno-missing-braces option
On Tue, Jun 24, 2014 at 7:02 PM, Gao, Liming <lim...@in...> wrote:
> Lzalo:
> For your patch for OVMF platform, could you provide the commit log message to me? Then, I will help commit it. Last, I commit this BaseTools Conf change.
Liming,
Laszlo is wisely a git user. :) Therefore his patch included a commit message. If you open 0004-OvmfPkg-add-missing-braces-to-aggregate-and-or-union.patch, then you will see:
---
Subject: [PATCH 4/4] OvmfPkg: add missing braces to aggregate and/or union initializers
Lack of these braces causes build errors when -Wno-missing-braces is absent. Spelling out more braces also helps understanding the code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <le...@re...>
---
git puts the first line of the commit message as the subject. This helps because when git send-email is used, then people have a good idea of what the patch is about from the subject of the email.
So, Laszlo's commit message was:
===
OvmfPkg: add missing braces to aggregate and/or union initializers
Lack of these braces causes build errors when -Wno-missing-braces is absent. Spelling out more braces also helps understanding the code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <le...@re...> ===
The git command 'git am' will take an email message (or git patch attached to an email), and apply the patch along with the commit message making it very easy for the patch submitter to send the patch along with a good commit message, and also making it very easy for the maintainer to incorporate that patch into the tree.
Laszlo,
Your 0004 patch is Reviewed-by: Jordan Justen <jor...@in...>, and committed. I think it is usually better to use git send-email with patches, rather than attaching them because they are more easy to notice and to code review.
Thanks for the contribution!
-Jordan
> -----Original Message-----
> From: Gao, Liming [mailto:lim...@in...]
> Sent: Monday, June 23, 2014 1:16 PM
> To: Olivier Martin; edk...@li...;
> edk...@li...
> Subject: Re: [edk2-buildtools] [edk2] [Patch] Remove GCC option
> -Wno-missing-braces option
>
> Lzalo:
> This patch includes the change to *_ELFGCC_X64_CC_FLAGS. But, no changes is for XCLANG and XCODE. If Andrew agrees this change, I can apply it in XCLANG and XCODE tool chain.
>
> 4) I only verify it in common package. Thanks for your test on other
> platforms. Your patch for OVMF platform is good to me. Reviewed-by:
> Gao, Liming <lim...@in...>
>
> Thanks
> Liming
> -----Original Message-----
> From: Olivier Martin [mailto:oli...@ar...]
> Sent: Friday, June 20, 2014 9:30 PM
> To: edk...@li...; Gao, Liming;
> edk...@li...
> Subject: RE: [edk2] [edk2-buildtools] [Patch] Remove GCC option
> -Wno-missing-braces option
>
> Thanks Lazlo, I was actually doing the same exercise with our build system.
> I am still going through them...
>
> But as far as I have seen, there is no error int the common packages. So the patch looks fine to me.
>
> Reviewed-By: Olivier Martin <Oli...@ar...>
> Tested-By: Olivier Martin <Oli...@ar...>
>
>
>
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:le...@re...]
>> Sent: 20 June 2014 14:17
>> To: Gao, Liming; edk...@li...; edk2-
>> de...@li...
>> Subject: Re: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-
>> missing-braces option
>>
>> On 06/20/14 12:00, Gao, Liming wrote:
>> > Hi, all
>> >
>> > -Wno-missing-braces option is used to disable warning when the
>> > initialized value without braces is set into structure. To remove
>> this
>> > option can detect such wrong case in source code. This patch remove
>> it
>> > from the default GCC compiler option in
>> > BaseTools/Conf/tools_def.template. Please help review it.
>>
>> (1) The patch makes sense to me, because a human should arguably
>> prefer
>>
>> int b[2][2] = { { 0, 1 }, { 2, 3 } };
>>
>> over
>>
>> int a[2][2] = { 0, 1, 2, 3 };
>>
>> It could be a little inconvenient for machine generated code though.
>> (Especially that the warning will be treated as an error.) But I
>> guess it should be fine.
>>
>> (2) The patch removes the flag from two GCC defines (GCC_ALL_CC_FLAGS
>> and GCC44_ALL_CC_FLAGS). In my edk2 clone there's a third, similar
>> flag:
>> "*_ELFGCC_X64_CC_FLAGS". Did you leave that out deliberately?
>>
>> (3) Other compilers seem to retain -Wno-missing-braces (eg. XCLANG,
>> XCODE). Is that intentional, or are they not modified only because
>> it's hard to test them? (I don't mind if the latter is the case, I'd
>> just like to understand.)
>>
>> (4) In order to test the patch, I grabbed my existing
>> "Conf/tools_def.txt" and removed all instances of -Wno-missing-braces.
>>
>> Then I tried to build OVMF (for both Ia32 and X64), and also
>> (cross-build) "ArmVExpress-FVP-AArch64" and
>> "ArmVExpress-RTSM-AEMv8Ax4-foundation".
>>
>> The change triggers a few build errors in OVMF, and many more in the
>> ARM packages. Please see my attached fixes. I propose that these
>> patches be applied first (after review), before committing & syncing
>> this BaseTools change.
>>
>> Thanks
>> Laszlo
>
>
>
>
> ----------------------------------------------------------------------
> -------- HPCC Systems Open Source Big Data Platform from LexisNexis
> Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
>
> ----------------------------------------------------------------------
> -------- Open source business process management suite built on Java
> and Eclipse Turn processes into business applications with Bonita BPM
> Community Edition Quickly connect people, data, and systems into
> organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
|
|
From: Jordan J. <jlj...@gm...> - 2014-06-25 03:49:09
|
On Tue, Jun 24, 2014 at 7:02 PM, Gao, Liming <lim...@in...> wrote:
> Lzalo:
> For your patch for OVMF platform, could you provide the commit log message to me? Then, I will help commit it. Last, I commit this BaseTools Conf change.
Liming,
Laszlo is wisely a git user. :) Therefore his patch included a commit
message. If you open
0004-OvmfPkg-add-missing-braces-to-aggregate-and-or-union.patch, then
you will see:
---
Subject: [PATCH 4/4] OvmfPkg: add missing braces to aggregate and/or union
initializers
Lack of these braces causes build errors when -Wno-missing-braces is
absent. Spelling out more braces also helps understanding the code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <le...@re...>
---
git puts the first line of the commit message as the subject. This
helps because when git send-email is used, then people have a good
idea of what the patch is about from the subject of the email.
So, Laszlo's commit message was:
===
OvmfPkg: add missing braces to aggregate and/or union initializers
Lack of these braces causes build errors when -Wno-missing-braces is
absent. Spelling out more braces also helps understanding the code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <le...@re...>
===
The git command 'git am' will take an email message (or git patch
attached to an email), and apply the patch along with the commit
message making it very easy for the patch submitter to send the patch
along with a good commit message, and also making it very easy for the
maintainer to incorporate that patch into the tree.
Laszlo,
Your 0004 patch is Reviewed-by: Jordan Justen
<jor...@in...>, and committed. I think it is usually
better to use git send-email with patches, rather than attaching them
because they are more easy to notice and to code review.
Thanks for the contribution!
-Jordan
> -----Original Message-----
> From: Gao, Liming [mailto:lim...@in...]
> Sent: Monday, June 23, 2014 1:16 PM
> To: Olivier Martin; edk...@li...; edk...@li...
> Subject: Re: [edk2-buildtools] [edk2] [Patch] Remove GCC option -Wno-missing-braces option
>
> Lzalo:
> This patch includes the change to *_ELFGCC_X64_CC_FLAGS. But, no changes is for XCLANG and XCODE. If Andrew agrees this change, I can apply it in XCLANG and XCODE tool chain.
>
> 4) I only verify it in common package. Thanks for your test on other platforms. Your patch for OVMF platform is good to me. Reviewed-by: Gao, Liming <lim...@in...>
>
> Thanks
> Liming
> -----Original Message-----
> From: Olivier Martin [mailto:oli...@ar...]
> Sent: Friday, June 20, 2014 9:30 PM
> To: edk...@li...; Gao, Liming; edk...@li...
> Subject: RE: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-missing-braces option
>
> Thanks Lazlo, I was actually doing the same exercise with our build system.
> I am still going through them...
>
> But as far as I have seen, there is no error int the common packages. So the patch looks fine to me.
>
> Reviewed-By: Olivier Martin <Oli...@ar...>
> Tested-By: Olivier Martin <Oli...@ar...>
>
>
>
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:le...@re...]
>> Sent: 20 June 2014 14:17
>> To: Gao, Liming; edk...@li...; edk2-
>> de...@li...
>> Subject: Re: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-
>> missing-braces option
>>
>> On 06/20/14 12:00, Gao, Liming wrote:
>> > Hi, all
>> >
>> > -Wno-missing-braces option is used to disable warning when the
>> > initialized value without braces is set into structure. To remove
>> this
>> > option can detect such wrong case in source code. This patch remove
>> it
>> > from the default GCC compiler option in
>> > BaseTools/Conf/tools_def.template. Please help review it.
>>
>> (1) The patch makes sense to me, because a human should arguably
>> prefer
>>
>> int b[2][2] = { { 0, 1 }, { 2, 3 } };
>>
>> over
>>
>> int a[2][2] = { 0, 1, 2, 3 };
>>
>> It could be a little inconvenient for machine generated code though.
>> (Especially that the warning will be treated as an error.) But I guess
>> it should be fine.
>>
>> (2) The patch removes the flag from two GCC defines (GCC_ALL_CC_FLAGS
>> and GCC44_ALL_CC_FLAGS). In my edk2 clone there's a third, similar
>> flag:
>> "*_ELFGCC_X64_CC_FLAGS". Did you leave that out deliberately?
>>
>> (3) Other compilers seem to retain -Wno-missing-braces (eg. XCLANG,
>> XCODE). Is that intentional, or are they not modified only because
>> it's hard to test them? (I don't mind if the latter is the case, I'd
>> just like to understand.)
>>
>> (4) In order to test the patch, I grabbed my existing
>> "Conf/tools_def.txt" and removed all instances of -Wno-missing-braces.
>>
>> Then I tried to build OVMF (for both Ia32 and X64), and also
>> (cross-build) "ArmVExpress-FVP-AArch64" and
>> "ArmVExpress-RTSM-AEMv8Ax4-foundation".
>>
>> The change triggers a few build errors in OVMF, and many more in the
>> ARM packages. Please see my attached fixes. I propose that these
>> patches be applied first (after review), before committing & syncing
>> this BaseTools change.
>>
>> Thanks
>> Laszlo
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
|
|
From: Gao, L. <lim...@in...> - 2014-06-25 02:03:33
|
Lzalo:
For your patch for OVMF platform, could you provide the commit log message to me? Then, I will help commit it. Last, I commit this BaseTools Conf change.
Thanks
Liming
-----Original Message-----
From: Gao, Liming [mailto:lim...@in...]
Sent: Monday, June 23, 2014 1:16 PM
To: Olivier Martin; edk...@li...; edk...@li...
Subject: Re: [edk2-buildtools] [edk2] [Patch] Remove GCC option -Wno-missing-braces option
Lzalo:
This patch includes the change to *_ELFGCC_X64_CC_FLAGS. But, no changes is for XCLANG and XCODE. If Andrew agrees this change, I can apply it in XCLANG and XCODE tool chain.
4) I only verify it in common package. Thanks for your test on other platforms. Your patch for OVMF platform is good to me. Reviewed-by: Gao, Liming <lim...@in...>
Thanks
Liming
-----Original Message-----
From: Olivier Martin [mailto:oli...@ar...]
Sent: Friday, June 20, 2014 9:30 PM
To: edk...@li...; Gao, Liming; edk...@li...
Subject: RE: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-missing-braces option
Thanks Lazlo, I was actually doing the same exercise with our build system.
I am still going through them...
But as far as I have seen, there is no error int the common packages. So the patch looks fine to me.
Reviewed-By: Olivier Martin <Oli...@ar...>
Tested-By: Olivier Martin <Oli...@ar...>
> -----Original Message-----
> From: Laszlo Ersek [mailto:le...@re...]
> Sent: 20 June 2014 14:17
> To: Gao, Liming; edk...@li...; edk2-
> de...@li...
> Subject: Re: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-
> missing-braces option
>
> On 06/20/14 12:00, Gao, Liming wrote:
> > Hi, all
> >
> > -Wno-missing-braces option is used to disable warning when the
> > initialized value without braces is set into structure. To remove
> this
> > option can detect such wrong case in source code. This patch remove
> it
> > from the default GCC compiler option in
> > BaseTools/Conf/tools_def.template. Please help review it.
>
> (1) The patch makes sense to me, because a human should arguably
> prefer
>
> int b[2][2] = { { 0, 1 }, { 2, 3 } };
>
> over
>
> int a[2][2] = { 0, 1, 2, 3 };
>
> It could be a little inconvenient for machine generated code though.
> (Especially that the warning will be treated as an error.) But I guess
> it should be fine.
>
> (2) The patch removes the flag from two GCC defines (GCC_ALL_CC_FLAGS
> and GCC44_ALL_CC_FLAGS). In my edk2 clone there's a third, similar
> flag:
> "*_ELFGCC_X64_CC_FLAGS". Did you leave that out deliberately?
>
> (3) Other compilers seem to retain -Wno-missing-braces (eg. XCLANG,
> XCODE). Is that intentional, or are they not modified only because
> it's hard to test them? (I don't mind if the latter is the case, I'd
> just like to understand.)
>
> (4) In order to test the patch, I grabbed my existing
> "Conf/tools_def.txt" and removed all instances of -Wno-missing-braces.
>
> Then I tried to build OVMF (for both Ia32 and X64), and also
> (cross-build) "ArmVExpress-FVP-AArch64" and
> "ArmVExpress-RTSM-AEMv8Ax4-foundation".
>
> The change triggers a few build errors in OVMF, and many more in the
> ARM packages. Please see my attached fixes. I propose that these
> patches be applied first (after review), before committing & syncing
> this BaseTools change.
>
> Thanks
> Laszlo
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________
edk2-buildtools-devel mailing list
edk...@li...
https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
|
|
From: Laszlo E. <le...@re...> - 2014-06-24 12:29:00
|
On 06/24/14 11:55, Paolo Bonzini wrote:
> As long as $EDK_TOOLS_PATH is properly set, the BaseTools/ directory
> is not necessary in the workspace. The BuildEnv file itself suggests
> setting the variable if BaseTools/ is not available.
>
> However, this only works if the user also sets $WORKSPACE. Otherwise,
> BuildEnv refuses to set WORKSPACE itself and does not even try to use
> the preset $EDK_TOOLS_PATH. Remove the check that fails, as it does
> not have any practical benefit.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini <pbo...@re...>
>
> --- a/BaseTools/BuildEnv
> +++ b/BaseTools/BuildEnv
> @@ -23,14 +23,6 @@
> return 0
> fi
>
> - if [ ! ${BASH_SOURCE[0]} -ef ./BaseTools/BuildEnv ]
> - then
> - echo Run this script from the base of your tree. For example:
> - echo " cd /Path/To/Edk/Root"
> - echo " . BaseTools/BuildEnv"
> - return 1
> - fi
> -
> #
> # Set $WORKSPACE
> #
>
The calls go like
ScriptMain
SetWorkspace
SetEdkToolsPath
"SetEdkToolsPath" prints the message you refer to (as last resort):
--------
Unable to determine EDK_TOOLS_PATH
You may need to download the 'BaseTools' from buildtools.tianocore.org.
After downloading, either create a symbolic link to the source at
$WORKSPACE/Conf/BaseToolsSource, or set the EDK_TOOLS_PATH environment
variable.
--------
The code being removed checks if "./BaseTools/BuildEnv" is the same
script file (by device and inode numbers) as the one executing (whether
forked or sourced). This seems to be the polar opposite of what
EDK_TOOLS_PATH is supposed to enable -- an out-of-WORKSPACE (== $PWD)
BaseTools subdir. I checked the commit log but still can't figure out
why this check was added in the first place.
If the SetWorkspace function only wants to ensure that it is called from
the root of an edk2 clone (ie. a WORKSPACE candidate), then it should
check eg. for the existence of "./MdePkg/MdePkg.dec", rather than
depending on an embedded BaseTools (which defeats EDK_TOOLS_PATH).
If that's the case, then I think the following patch would be preferable:
--------
diff --git a/BaseTools/BuildEnv b/BaseTools/BuildEnv
index cccc753..d85c967 100755
--- a/BaseTools/BuildEnv
+++ b/BaseTools/BuildEnv
@@ -23,7 +23,7 @@ SetWorkspace() {
return 0
fi
- if [ ! ${BASH_SOURCE[0]} -ef ./BaseTools/BuildEnv ]
+ if [ ! -e MdePkg/MdePkg.dec ]
then
echo Run this script from the base of your tree. For example:
echo " cd /Path/To/Edk/Root"
--------
Ie. the current code does have one practical benefit -- a basic sanity
check that you are standing in an edk2 root dir -- but the
implementation incurs an unnecessary dependency on BaseTools. Let's keep
the intent, just improve the implementation.
What do others think?
Thanks,
Laszlo
|
|
From: Laszlo E. <le...@re...> - 2014-06-24 12:03:03
|
On 06/24/14 13:50, Paolo Bonzini wrote: > Il 24/06/2014 13:33, Laszlo Ersek ha scritto: >> The code being removed checks if "./BaseTools/BuildEnv" is the same >> script file (by device and inode numbers) as the one executing (whether >> forked or sourced). This seems to be the polar opposite of what >> EDK_TOOLS_PATH is supposed to enable -- an out-of-WORKSPACE (== $PWD) >> BaseTools subdir. I checked the commit log but still can't figure out >> why this check was added in the first place. >> >> If the SetWorkspace function only wants to ensure that it is called from >> the root of an edk2 clone (ie. a WORKSPACE candidate), then it should >> check eg. for the existence of "./MdePkg/MdePkg.dec", rather than >> depending on an embedded BaseTools (which defeats EDK_TOOLS_PATH). > > I agree that having a check like this makes a lot of sense. However, > BaseTools should not have dependencies on the layout of EDK2, I think. > Perhaps this check should be in edksetup.sh's SetupEnv rather than > BaseTools/BuildEnv? Good point. Laszlo |
|
From: Paolo B. <pbo...@re...> - 2014-06-24 11:51:12
|
Il 24/06/2014 13:33, Laszlo Ersek ha scritto:
> The code being removed checks if "./BaseTools/BuildEnv" is the same
> script file (by device and inode numbers) as the one executing (whether
> forked or sourced). This seems to be the polar opposite of what
> EDK_TOOLS_PATH is supposed to enable -- an out-of-WORKSPACE (== $PWD)
> BaseTools subdir. I checked the commit log but still can't figure out
> why this check was added in the first place.
>
> If the SetWorkspace function only wants to ensure that it is called from
> the root of an edk2 clone (ie. a WORKSPACE candidate), then it should
> check eg. for the existence of "./MdePkg/MdePkg.dec", rather than
> depending on an embedded BaseTools (which defeats EDK_TOOLS_PATH).
I agree that having a check like this makes a lot of sense. However,
BaseTools should not have dependencies on the layout of EDK2, I think.
Perhaps this check should be in edksetup.sh's SetupEnv rather than
BaseTools/BuildEnv?
Paolo
> If that's the case, then I think the following patch would be preferable:
>
> --------
> diff --git a/BaseTools/BuildEnv b/BaseTools/BuildEnv
> index cccc753..d85c967 100755
> --- a/BaseTools/BuildEnv
> +++ b/BaseTools/BuildEnv
> @@ -23,7 +23,7 @@ SetWorkspace() {
> return 0
> fi
>
> - if [ ! ${BASH_SOURCE[0]} -ef ./BaseTools/BuildEnv ]
> + if [ ! -e MdePkg/MdePkg.dec ]
> then
> echo Run this script from the base of your tree. For example:
> echo " cd /Path/To/Edk/Root"
> --------
>
> Ie. the current code does have one practical benefit -- a basic sanity
> check that you are standing in an edk2 root dir -- but the
> implementation incurs an unnecessary dependency on BaseTools. Let's keep
> the intent, just improve the implementation.
|
|
From: Paolo B. <pbo...@re...> - 2014-06-24 09:55:26
|
As long as $EDK_TOOLS_PATH is properly set, the BaseTools/ directory
is not necessary in the workspace. The BuildEnv file itself suggests
setting the variable if BaseTools/ is not available.
However, this only works if the user also sets $WORKSPACE. Otherwise,
BuildEnv refuses to set WORKSPACE itself and does not even try to use
the preset $EDK_TOOLS_PATH. Remove the check that fails, as it does
not have any practical benefit.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbo...@re...>
--- a/BaseTools/BuildEnv
+++ b/BaseTools/BuildEnv
@@ -23,14 +23,6 @@
return 0
fi
- if [ ! ${BASH_SOURCE[0]} -ef ./BaseTools/BuildEnv ]
- then
- echo Run this script from the base of your tree. For example:
- echo " cd /Path/To/Edk/Root"
- echo " . BaseTools/BuildEnv"
- return 1
- fi
-
#
# Set $WORKSPACE
#
|
|
From: Gao, L. <lim...@in...> - 2014-06-23 05:16:19
|
Lzalo:
This patch includes the change to *_ELFGCC_X64_CC_FLAGS. But, no changes is for XCLANG and XCODE. If Andrew agrees this change, I can apply it in XCLANG and XCODE tool chain.
4) I only verify it in common package. Thanks for your test on other platforms. Your patch for OVMF platform is good to me. Reviewed-by: Gao, Liming <lim...@in...>
Thanks
Liming
-----Original Message-----
From: Olivier Martin [mailto:oli...@ar...]
Sent: Friday, June 20, 2014 9:30 PM
To: edk...@li...; Gao, Liming; edk...@li...
Subject: RE: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-missing-braces option
Thanks Lazlo, I was actually doing the same exercise with our build system.
I am still going through them...
But as far as I have seen, there is no error int the common packages. So the patch looks fine to me.
Reviewed-By: Olivier Martin <Oli...@ar...>
Tested-By: Olivier Martin <Oli...@ar...>
> -----Original Message-----
> From: Laszlo Ersek [mailto:le...@re...]
> Sent: 20 June 2014 14:17
> To: Gao, Liming; edk...@li...; edk2-
> de...@li...
> Subject: Re: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-
> missing-braces option
>
> On 06/20/14 12:00, Gao, Liming wrote:
> > Hi, all
> >
> > -Wno-missing-braces option is used to disable warning when the
> > initialized value without braces is set into structure. To remove
> this
> > option can detect such wrong case in source code. This patch remove
> it
> > from the default GCC compiler option in
> > BaseTools/Conf/tools_def.template. Please help review it.
>
> (1) The patch makes sense to me, because a human should arguably
> prefer
>
> int b[2][2] = { { 0, 1 }, { 2, 3 } };
>
> over
>
> int a[2][2] = { 0, 1, 2, 3 };
>
> It could be a little inconvenient for machine generated code though.
> (Especially that the warning will be treated as an error.) But I guess
> it should be fine.
>
> (2) The patch removes the flag from two GCC defines (GCC_ALL_CC_FLAGS
> and GCC44_ALL_CC_FLAGS). In my edk2 clone there's a third, similar
> flag:
> "*_ELFGCC_X64_CC_FLAGS". Did you leave that out deliberately?
>
> (3) Other compilers seem to retain -Wno-missing-braces (eg. XCLANG,
> XCODE). Is that intentional, or are they not modified only because
> it's hard to test them? (I don't mind if the latter is the case, I'd
> just like to understand.)
>
> (4) In order to test the patch, I grabbed my existing
> "Conf/tools_def.txt" and removed all instances of -Wno-missing-braces.
>
> Then I tried to build OVMF (for both Ia32 and X64), and also
> (cross-build) "ArmVExpress-FVP-AArch64" and
> "ArmVExpress-RTSM-AEMv8Ax4-foundation".
>
> The change triggers a few build errors in OVMF, and many more in the
> ARM packages. Please see my attached fixes. I propose that these
> patches be applied first (after review), before committing & syncing
> this BaseTools change.
>
> Thanks
> Laszlo
|
|
From: Olivier M. <oli...@ar...> - 2014-06-20 13:30:09
|
Thanks Lazlo, I was actually doing the same exercise with our build system.
I am still going through them...
But as far as I have seen, there is no error int the common packages. So the
patch looks fine to me.
Reviewed-By: Olivier Martin <Oli...@ar...>
Tested-By: Olivier Martin <Oli...@ar...>
> -----Original Message-----
> From: Laszlo Ersek [mailto:le...@re...]
> Sent: 20 June 2014 14:17
> To: Gao, Liming; edk...@li...; edk2-
> de...@li...
> Subject: Re: [edk2] [edk2-buildtools] [Patch] Remove GCC option -Wno-
> missing-braces option
>
> On 06/20/14 12:00, Gao, Liming wrote:
> > Hi, all
> >
> > -Wno-missing-braces option is used to disable warning when the
> > initialized value without braces is set into structure. To remove
> this
> > option can detect such wrong case in source code. This patch remove
> it
> > from the default GCC compiler option in
> > BaseTools/Conf/tools_def.template. Please help review it.
>
> (1) The patch makes sense to me, because a human should arguably prefer
>
> int b[2][2] = { { 0, 1 }, { 2, 3 } };
>
> over
>
> int a[2][2] = { 0, 1, 2, 3 };
>
> It could be a little inconvenient for machine generated code though.
> (Especially that the warning will be treated as an error.) But I guess
> it should be fine.
>
> (2) The patch removes the flag from two GCC defines (GCC_ALL_CC_FLAGS
> and GCC44_ALL_CC_FLAGS). In my edk2 clone there's a third, similar
> flag:
> "*_ELFGCC_X64_CC_FLAGS". Did you leave that out deliberately?
>
> (3) Other compilers seem to retain -Wno-missing-braces (eg. XCLANG,
> XCODE). Is that intentional, or are they not modified only because it's
> hard to test them? (I don't mind if the latter is the case, I'd just
> like to understand.)
>
> (4) In order to test the patch, I grabbed my existing
> "Conf/tools_def.txt" and removed all instances of -Wno-missing-braces.
>
> Then I tried to build OVMF (for both Ia32 and X64), and also
> (cross-build) "ArmVExpress-FVP-AArch64" and
> "ArmVExpress-RTSM-AEMv8Ax4-foundation".
>
> The change triggers a few build errors in OVMF, and many more in the
> ARM
> packages. Please see my attached fixes. I propose that these patches be
> applied first (after review), before committing & syncing this
> BaseTools
> change.
>
> Thanks
> Laszlo
|
|
From: Laszlo E. <le...@re...> - 2014-06-20 13:17:09
|
On 06/20/14 12:00, Gao, Liming wrote:
> Hi, all
>
> -Wno-missing-braces option is used to disable warning when the
> initialized value without braces is set into structure. To remove this
> option can detect such wrong case in source code. This patch remove it
> from the default GCC compiler option in
> BaseTools/Conf/tools_def.template. Please help review it.
(1) The patch makes sense to me, because a human should arguably prefer
int b[2][2] = { { 0, 1 }, { 2, 3 } };
over
int a[2][2] = { 0, 1, 2, 3 };
It could be a little inconvenient for machine generated code though.
(Especially that the warning will be treated as an error.) But I guess
it should be fine.
(2) The patch removes the flag from two GCC defines (GCC_ALL_CC_FLAGS
and GCC44_ALL_CC_FLAGS). In my edk2 clone there's a third, similar flag:
"*_ELFGCC_X64_CC_FLAGS". Did you leave that out deliberately?
(3) Other compilers seem to retain -Wno-missing-braces (eg. XCLANG,
XCODE). Is that intentional, or are they not modified only because it's
hard to test them? (I don't mind if the latter is the case, I'd just
like to understand.)
(4) In order to test the patch, I grabbed my existing
"Conf/tools_def.txt" and removed all instances of -Wno-missing-braces.
Then I tried to build OVMF (for both Ia32 and X64), and also
(cross-build) "ArmVExpress-FVP-AArch64" and
"ArmVExpress-RTSM-AEMv8Ax4-foundation".
The change triggers a few build errors in OVMF, and many more in the ARM
packages. Please see my attached fixes. I propose that these patches be
applied first (after review), before committing & syncing this BaseTools
change.
Thanks
Laszlo
|
|
From: Laszlo E. <le...@re...> - 2014-06-16 11:34:11
|
On 06/16/14 09:32, Eliyahu, Gil wrote: > Hi , > > I got this error when I tried the MyHelloWorld.c example. > > Please advice . > > build... > > : error C0DE: Unknown fatal error when processing > [c:\edk2\MyHelloWorld\MyHello > > World.inf] > > > > (Please send email to edk...@li... > <mailto:edk...@li...> for help, atta > > ching following call stack trace!) > > > > (Python 2.7.3 on win32) Traceback (most recent call last): > > File "build.py", line 1828, in Main > > File "build.py", line 1595, in Launch > > File "build.py", line 1427, in _MultiThreadBuildPlatform > > File > "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", l > > ine 3057, in CreateCodeFile > > File > "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", l > > ine 2607, in _GetAutoGenFileList > > File > "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\GenC.py", line > > 1536, in CreateCode > > File > "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\GenC.py", line > > 1498, in CreateHeaderCode > > File > "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Common\Misc.py", line > > 81, in GuidStringToGuidStructureString > > IndexError: list index out of range > > > > > > - Failed - > > Build end time: 10:13:02, Jun.16 2014 > > Build total time: 00:01:25 You passed garbage in your INF file's [Defines] / FILE_GUID value. Laszlo |
|
From: Eliyahu, G. <gil...@in...> - 2014-06-16 07:32:56
|
Hi , I got this error when I tried the MyHelloWorld.c example. Please advice . Thanks Gil build... : error C0DE: Unknown fatal error when processing [c:\edk2\MyHelloWorld\MyHello World.inf] (Please send email to edk...@li...<mailto:edk...@li...> for help, atta ching following call stack trace!) (Python 2.7.3 on win32) Traceback (most recent call last): File "build.py", line 1828, in Main File "build.py", line 1595, in Launch File "build.py", line 1427, in _MultiThreadBuildPlatform File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", l ine 3057, in CreateCodeFile File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", l ine 2607, in _GetAutoGenFileList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\GenC.py", line 1536, in CreateCode File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\GenC.py", line 1498, in CreateHeaderCode File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Common\Misc.py", line 81, in GuidStringToGuidStructureString IndexError: list index out of range - Failed - Build end time: 10:13:02, Jun.16 2014 Build total time: 00:01:25 c:\edk2> --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: Dong, E. <eri...@in...> - 2014-06-10 07:27:49
|
Aaron,
The remove is intentional, this code always report error if two questions share one variable and all set default value for it. But this patch is used to let user to decide when print warning or error info when question has more than one default value.
I think it's the author's response to check whether same variable has been shared by two different questions and set different default value.
Thanks,
Eric
From: Aaron Pop [mailto:aa...@am...]
Sent: Tuesday, June 10, 2014 5:32 AM
To: edk...@li...
Subject: [edk2-buildtools] Question about VfrCompile and
Revision 2594 of the VfrUtilityLib.cpp removed the reporting of an error when multiple questions define a default value for the same offset/Width/Value in a Buffer varstore. (CVfrBufferConfig::Write used to return VFR_RETURN_DEFAULT_VALUE_REDEFINED for this)
The changes associated with those check-ins were to support "Reporting a warning info or error info when two defaults value is set for one question."
I wanted to check if the changes in the VfrUtilityLib.cpp were intentional, because it exposes a possible problem when there are two separate questions that have different default values declared, as in the example below. Was this an oversight in the check-in, or is this the desired behavior for the VfrCompile to allow multiple questions to specify a default value?
Thank you for your help in clarifying this,
Aaron
typedef struct
{
UINT8 U8;
} VAR_1;
formset guid = {0x2b39d40a, 0x90f9, 0x46fa, 0xb9, 0x2a, 0x60, 0xb, 0xdd, 0x9b, 0x8d, 0x2e},
title = STRING_TOKEN(1),
help = STRING_TOKEN(2),
class = 0x500,
subclass = 0,
varstore VAR_1,
key = 100,
name = Variable1,
guid = { 0x98dd6165, 0xc3c0, 0x43b1, 0xa3, 0x5, 0x7e, 0x0, 0xe6, 0xd2, 0xe7, 0x7e };
form formid = 1,
title = STRING_TOKEN(1);
oneof varid = VAR_1.U8,
prompt = STRING_TOKEN(1),
help = STRING_TOKEN(1),
flags = 0,
option text = STRING_TOKEN(1), value = 0, flags = DEFAULT;
option text = STRING_TOKEN(1), value = 1, flags = 0;
endoneof;
oneof varid = VAR_1.U8,
prompt = STRING_TOKEN(3),
help = STRING_TOKEN(4),
flags = 0,
option text = STRING_TOKEN(1), value = 2, flags = 0;
option text = STRING_TOKEN(1), value = 3, flags = DEFAULT;
endoneof;
endform;
endformset;
VfrCompile...
Duplicate.vfr(33): ERROR 12288
: default value re-defined with different value
VfrCompile: ERROR 0003: Error parsing
compile error in file Duplicate.vfr
The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
|
|
From: Aaron P. <aa...@am...> - 2014-06-09 21:33:07
|
Revision 2594 of the VfrUtilityLib.cpp removed the reporting of an error when multiple questions define a default value for the same offset/Width/Value in a Buffer varstore. (CVfrBufferConfig::Write used to return VFR_RETURN_DEFAULT_VALUE_REDEFINED for this)
The changes associated with those check-ins were to support "Reporting a warning info or error info when two defaults value is set for one question."
I wanted to check if the changes in the VfrUtilityLib.cpp were intentional, because it exposes a possible problem when there are two separate questions that have different default values declared, as in the example below. Was this an oversight in the check-in, or is this the desired behavior for the VfrCompile to allow multiple questions to specify a default value?
Thank you for your help in clarifying this,
Aaron
typedef struct
{
UINT8 U8;
} VAR_1;
formset guid = {0x2b39d40a, 0x90f9, 0x46fa, 0xb9, 0x2a, 0x60, 0xb, 0xdd, 0x9b, 0x8d, 0x2e},
title = STRING_TOKEN(1),
help = STRING_TOKEN(2),
class = 0x500,
subclass = 0,
varstore VAR_1,
key = 100,
name = Variable1,
guid = { 0x98dd6165, 0xc3c0, 0x43b1, 0xa3, 0x5, 0x7e, 0x0, 0xe6, 0xd2, 0xe7, 0x7e };
form formid = 1,
title = STRING_TOKEN(1);
oneof varid = VAR_1.U8,
prompt = STRING_TOKEN(1),
help = STRING_TOKEN(1),
flags = 0,
option text = STRING_TOKEN(1), value = 0, flags = DEFAULT;
option text = STRING_TOKEN(1), value = 1, flags = 0;
endoneof;
oneof varid = VAR_1.U8,
prompt = STRING_TOKEN(3),
help = STRING_TOKEN(4),
flags = 0,
option text = STRING_TOKEN(1), value = 2, flags = 0;
option text = STRING_TOKEN(1), value = 3, flags = DEFAULT;
endoneof;
endform;
endformset;
VfrCompile...
Duplicate.vfr(33): ERROR 12288
: default value re-defined with different value
VfrCompile: ERROR 0003: Error parsing
compile error in file Duplicate.vfr
The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
|
|
From: Dong, E. <eri...@in...> - 2014-06-09 11:03:21
|
This issue has fixed at version 2667. Thanks for the contribution from Reza.
Thanks,
Eric
-----Original Message-----
From: Jordan Justen [mailto:jlj...@gm...]
Sent: Monday, June 09, 2014 8:23 AM
To: Piotr Król; Reza Jelveh
Cc: edk...@li...
Subject: Re: [edk2-buildtools] VfrCompiler: mRunStatus is used unintialized
On Sun, Jun 8, 2014 at 4:01 PM, Piotr Król <pie...@gm...> wrote:
> Hello,
> I found that mRunStatus is used uninitialized in VfrCompiler.cpp:56.
> This cause problems at least for some versions of g++ (4.8.3-3,
> 4.7.3-14, 4.6.4-7) on my Debian. Compilation works when mRunStatus
> contain some big value out of COMPILER_RUN_STATUS range (this happens
> when I use i.e. g++ 4.7.2-5), but if it contain for example
> STATUS_FAILED VfrCompiler fails.
I think Reza submitted a patch on April 7 that might fix this.
("BaseTools: fix undefined behaviour in VfrCompiler")
I asked if the commit message could be improved, and I guess nothing happened with the patch after that.
-Jordan
> Other thing is that VfrCompiler.cpp doesn't contain mRunStatus range
> validation.
>
> What about enabling -Wall for BaseTools ?
>
> Thanks,
> Piotr Król
>
> ----------------------------------------------------------------------
> -------- Learn Graph Databases - Download FREE O'Reilly Book "Graph
> Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field, this
> first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com _______________________________________________
edk2-buildtools-devel mailing list
edk...@li...
https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
|
|
From: Dong, E. <eri...@in...> - 2014-06-09 11:01:36
|
Aaron, Has checked in your patch at version 2665. Thanks for your contribution. Thanks, Eric From: Aaron Pop [mailto:aa...@am...] Sent: Friday, June 06, 2014 12:08 AM To: edk...@li... Subject: [edk2-buildtools] [Patch] String To Integer Overflow Detection Attached is another patch for the VfrCompiler's string to integer functions (STOU8, STOU16, STOU32, STOU64). The functions were not detecting when overflow occurred while converting a string to an integer value. (i.e. when "256" was being converted into a UINT8, it would be allowed and would result in the UINT8 value of 0 being returned). The patch will now report an error message containing the original value and that the value is too large for storage in the variable type (UINT8, UINT16, etc). Regards, Aaron The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. |
|
From: Dong, E. <eri...@in...> - 2014-06-09 11:01:17
|
Aaron, Has checked in your patch at version 2666. Thanks for your contribution. Thanks, Eric From: Aaron Pop [mailto:aa...@am...] Sent: Thursday, June 05, 2014 10:43 PM To: edk...@li... Subject: [edk2-buildtools] [Patch] Allow EFI_IFR_DISPLAY_INT_DEC flag for EFI_NUMERIC I've attached a patch file to address an issue with the VfrCompiler's treatment of the display flags for VFR numeric statements. Prior to this patch, the vfrcompiler would never allow the IFR output to contain the flag to cause a numeric to be displayed as a signed integer. The CIfrNumeric class's SetFlags function, treats the EFI_IFR_DISPLAY_INT_DEC (0x00) as if a display setting was not specified, and would change the flags to EFI_IFR_DISPLAY_UINT_DEC (0x10). To detect if a display setting was specified, the numericFlagsField syntax was modified to accept a "IsDisplaySpecified" parameter (similar to how the IsSetType was added to support the Numeric size). Regards, Aaron The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. |
|
From: Jordan J. <jlj...@gm...> - 2014-06-09 00:22:44
|
On Sun, Jun 8, 2014 at 4:01 PM, Piotr Król <pie...@gm...> wrote:
> Hello,
> I found that mRunStatus is used uninitialized in VfrCompiler.cpp:56.
> This cause problems at least for some versions of g++ (4.8.3-3,
> 4.7.3-14, 4.6.4-7) on my Debian. Compilation works when mRunStatus
> contain some big value out of COMPILER_RUN_STATUS range (this happens
> when I use i.e. g++ 4.7.2-5), but if it contain for example
> STATUS_FAILED VfrCompiler fails.
I think Reza submitted a patch on April 7 that might fix this.
("BaseTools: fix undefined behaviour in VfrCompiler")
I asked if the commit message could be improved, and I guess nothing
happened with the patch after that.
-Jordan
> Other thing is that VfrCompiler.cpp doesn't contain mRunStatus range
> validation.
>
> What about enabling -Wall for BaseTools ?
>
> Thanks,
> Piotr Król
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
|
60 messages has been excluded from this view by a project administrator.
