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: Andrew F. <af...@ap...> - 2010-04-27 17:35:23
|
This is from edk2 svn r10430. I changed the NT32Pkg.fdf file in the following two ways and both times I got errors:
###BlockSize = 0x10000
###NumBlocks = 0x2a
BlockSize = 0x2a0000
#NumBlocks = 1
build...
c:\work\edk2tot\Nt32Pkg\Nt32Pkg.fdf(52): error 3000: Invalid syntax/format
expected block statement for Fd Section near line 34, column
17: 0x2a0000
###BlockSize = 0x10000
###NumBlocks = 0x2a
BlockSize = 0x2a0000
NumBlocks = 1
GenFds...
: error F003: Size of FV (FvRecovery) is larger than Region Size
0x280000 speciied.
The FDF_v1_21.pdf
BlockSize
One or More - Size of a block, optionally followed by number of blocks. Multiple BlockSize statements are legal, and the first statement represents block 0 (the first block) and subsequent BlockSize statements represent blocks 1 - N.
NumBlocks
Zero or one - The number of continuous blocks of size, BlockSize. If NumBlocks is not present, the number of blocks defaults to 1.
I did not see anything in the errata about about this statement in the FDF specification not being true. Seems reasonable for a capsule or memory mapped FD to have a single block.
Andrew Fish
|
|
From: Andrew F. <af...@ap...> - 2010-03-23 16:25:25
|
Liming, Looks like I did not have my environment configured correctly and I was doing nmakes not from edk2\BaseTools, but from edk2\BaseTools\Source. Also I had some local modifications. Some set of this seems to have caused my issue. Andrew Fish On Mar 23, 2010, at 12:52 AM, Gao, Liming wrote: > Andrew: > I have no VS2003 environment. But I test them on VS2005. The function in PeCoffLoaderEx.c file can do source level debug. > > You mean we can do source level debug in the main tool. But the main tool may also contain more than one source files, like GenFv tool. If .pdb file are overwritten, GenFv main source files should not do source level debug. So, I still think .pdf file should not be corrupted by compiler. > > Thanks > Liming > -----Original Message----- > From: Andrew Fish [mailto:af...@ap...] > Sent: 2010年3月23日 10:30 > To: Gao, Liming > Cc: edk...@li... > Subject: Re: [edk2-buildtools] Problem source level debugging C tools using VS2003 > > Gao, > > The function was in PeCoffLoaderEx.c. > > .pdb files are being created in the Conf directory and it looks like they get overwritten. You get source level debug in the main tools, but if you step into a function in the Conf directory you lose source level debug. You can step through the functions, but you can not see locals or globals. > > Andrew Fish > > > > > > On Mar 22, 2010, at 6:35 PM, Gao, Liming wrote: > >> Andrew: >> Compiler adds debug information to the exist .pdb file if these debug information is missed in .pdb file. It does not rewrite the previous .pdb file. So, I am strange why you can't do source level debug. Could you tell me what function in CommonLib can't be debugged correctly? >> >> Thanks >> Liming >> -----Original Message----- >> From: Andrew Fish [mailto:af...@ap...] >> Sent: 2010年3月23日 4:23 >> To: edk...@li... >> Subject: [edk2-buildtools] Problem source level debugging C tools using VS2003 >> >> I had an issue source level debugging a C tool. I figured out the issue was the code was in Sources/C/Common directory and since no -Fd was passed to the compiler the .pdb file had the default name. This meant that each object in the common directory was overwriting the previous objects .pdb file. >> >> If you add -Fd$(@R).pdb to the .c.obj target this problem goes away. Not since the tools had a final link stage in a unique directory the default .pdb name worked for those tools. The problem is the .pdb files for things in common was getting trashed and you could not source level debug through that code. >> >> I guess you could also add this to the .cpp.obj: rule. Could some one review my proposed change and check in the fix? >> >> Andrew Fish >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> edk2-buildtools-devel mailing list >> edk...@li... >> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > |
|
From: Gao, L. <lim...@in...> - 2010-03-23 07:53:42
|
Andrew: I have no VS2003 environment. But I test them on VS2005. The function in PeCoffLoaderEx.c file can do source level debug. You mean we can do source level debug in the main tool. But the main tool may also contain more than one source files, like GenFv tool. If .pdb file are overwritten, GenFv main source files should not do source level debug. So, I still think .pdf file should not be corrupted by compiler. Thanks Liming -----Original Message----- From: Andrew Fish [mailto:af...@ap...] Sent: 2010年3月23日 10:30 To: Gao, Liming Cc: edk...@li... Subject: Re: [edk2-buildtools] Problem source level debugging C tools using VS2003 Gao, The function was in PeCoffLoaderEx.c. .pdb files are being created in the Conf directory and it looks like they get overwritten. You get source level debug in the main tools, but if you step into a function in the Conf directory you lose source level debug. You can step through the functions, but you can not see locals or globals. Andrew Fish On Mar 22, 2010, at 6:35 PM, Gao, Liming wrote: > Andrew: > Compiler adds debug information to the exist .pdb file if these debug information is missed in .pdb file. It does not rewrite the previous .pdb file. So, I am strange why you can't do source level debug. Could you tell me what function in CommonLib can't be debugged correctly? > > Thanks > Liming > -----Original Message----- > From: Andrew Fish [mailto:af...@ap...] > Sent: 2010年3月23日 4:23 > To: edk...@li... > Subject: [edk2-buildtools] Problem source level debugging C tools using VS2003 > > I had an issue source level debugging a C tool. I figured out the issue was the code was in Sources/C/Common directory and since no -Fd was passed to the compiler the .pdb file had the default name. This meant that each object in the common directory was overwriting the previous objects .pdb file. > > If you add -Fd$(@R).pdb to the .c.obj target this problem goes away. Not since the tools had a final link stage in a unique directory the default .pdb name worked for those tools. The problem is the .pdb files for things in common was getting trashed and you could not source level debug through that code. > > I guess you could also add this to the .cpp.obj: rule. Could some one review my proposed change and check in the fix? > > Andrew Fish > > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2010-03-23 02:30:34
|
Gao, The function was in PeCoffLoaderEx.c. .pdb files are being created in the Conf directory and it looks like they get overwritten. You get source level debug in the main tools, but if you step into a function in the Conf directory you lose source level debug. You can step through the functions, but you can not see locals or globals. Andrew Fish On Mar 22, 2010, at 6:35 PM, Gao, Liming wrote: > Andrew: > Compiler adds debug information to the exist .pdb file if these debug information is missed in .pdb file. It does not rewrite the previous .pdb file. So, I am strange why you can't do source level debug. Could you tell me what function in CommonLib can't be debugged correctly? > > Thanks > Liming > -----Original Message----- > From: Andrew Fish [mailto:af...@ap...] > Sent: 2010年3月23日 4:23 > To: edk...@li... > Subject: [edk2-buildtools] Problem source level debugging C tools using VS2003 > > I had an issue source level debugging a C tool. I figured out the issue was the code was in Sources/C/Common directory and since no -Fd was passed to the compiler the .pdb file had the default name. This meant that each object in the common directory was overwriting the previous objects .pdb file. > > If you add -Fd$(@R).pdb to the .c.obj target this problem goes away. Not since the tools had a final link stage in a unique directory the default .pdb name worked for those tools. The problem is the .pdb files for things in common was getting trashed and you could not source level debug through that code. > > I guess you could also add this to the .cpp.obj: rule. Could some one review my proposed change and check in the fix? > > Andrew Fish > > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Gao, L. <lim...@in...> - 2010-03-23 01:36:12
|
Andrew: Compiler adds debug information to the exist .pdb file if these debug information is missed in .pdb file. It does not rewrite the previous .pdb file. So, I am strange why you can't do source level debug. Could you tell me what function in CommonLib can't be debugged correctly? Thanks Liming -----Original Message----- From: Andrew Fish [mailto:af...@ap...] Sent: 2010年3月23日 4:23 To: edk...@li... Subject: [edk2-buildtools] Problem source level debugging C tools using VS2003 I had an issue source level debugging a C tool. I figured out the issue was the code was in Sources/C/Common directory and since no -Fd was passed to the compiler the .pdb file had the default name. This meant that each object in the common directory was overwriting the previous objects .pdb file. If you add -Fd$(@R).pdb to the .c.obj target this problem goes away. Not since the tools had a final link stage in a unique directory the default .pdb name worked for those tools. The problem is the .pdb files for things in common was getting trashed and you could not source level debug through that code. I guess you could also add this to the .cpp.obj: rule. Could some one review my proposed change and check in the fix? Andrew Fish ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ edk2-buildtools-devel mailing list edk...@li... https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2010-03-22 20:23:09
|
I had an issue source level debugging a C tool. I figured out the issue was the code was in Sources/C/Common directory and since no -Fd was passed to the compiler the .pdb file had the default name. This meant that each object in the common directory was overwriting the previous objects .pdb file. If you add -Fd$(@R).pdb to the .c.obj target this problem goes away. Not since the tools had a final link stage in a unique directory the default .pdb name worked for those tools. The problem is the .pdb files for things in common was getting trashed and you could not source level debug through that code. I guess you could also add this to the .cpp.obj: rule. Could some one review my proposed change and check in the fix? Andrew Fish |
|
From: Andrew F. <af...@ap...> - 2010-03-20 17:26:54
|
Ken, We have been seeing hangs is OS X, Cygwin, and Windows. We are seeing hangs with MAX_CONCURRENT_THREAD_NUMBER = 1. make has a -j (--jobs=) option that allows parallel make assuming the makefiles are constructed properly. So maybe the simple solution would look like: build --preprocess make --jobs --directory=$(WORKSPACE)\Build\NT32\DEBUG_VS2003\IA32 build --postprocess Have the 1st phase of build process the DSC, DEC, INF files and autogen all the code. Then use make to do a parallel build. Then call build to post process the results of the build, like parse the FDF file and build the FVs. If the makefiles generated by build worked we could test the performance difference. I also think calling make directly would cause a lot of our hangs to go away. We could keep the current build scheme for nmake (it is really optimized for that) and add the ability to do a preprocess and postprocess step into the build command for people who wanted to use make. In a lot of our projects we find we don't end up using the target.txt file and we have a script or makefile to build our project. Given this it would be easy to call build, then make, then build. For example on the beableboard we have to generate a binary file that is used by the MASK ROM to turn on memory prior to buiding and after the build we generate debugger scripts in the projects Build directory. Andrew Fish On Mar 19, 2010, at 7:46 PM, Lu, Ken wrote: > Hi, Andrew: > I have a question; you mentioned here is multi-process or multi-thread? Do you mean when you enable MUTIL_THREAD in Conf/target.txt or from build command? > > The article you provide is a good investigation, and need a time to research….but I also find similar performance issue in wxPython environment. So personally, I almost give up use wxPython to write GUI but use C#/mono. > > I like you idea about use C code for muti-threading building, but it make big different between OS, as your known, threading.Thread in python is really a very basic wrapper. Because threading implementation is very dependent OS’s API and usage. I think Our build tool need try *not* use OS dependent code, … The tools are all coded to POSIX, so I think it would be possible. But using make would be simpler. > I guess the threading schedule cost which bring from muti-threading is much less than performance tuning which bring from multi-threading. So seems it is not much valuable for use C code to wrapper threading. Do you agree? After thinking about it I think using make is better. > > I notice you find a new issue, I want to confirm, do you mean after all make files are created, then you go to the folder of top makefile and type “nmake clean”, it does not work? If I run build for my project. Then I cd into Build\NT32\DEBUG_VS2003\IA32. nmake clean. nmake. The nmake will fail. The error message is can not open file ...object_flles.lst. > Thanks. > > Best Regard > K > --------------------------- > hear and you forget; see and you remember; do and you understand > > From: Andrew Fish [mailto:af...@ap...] > Sent: 2010年3月20日 6:17 > To: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] hang/deadlock with MultiThread build in build.py due to use of output pipes in popen() call > > One of my coworkers point out this: http://www.dabeaz.com/python/GIL.pdf about how python runs threads very slow, and slows down on multicore systems. > > So I guess I have to ask the question of why we have to wrap building the code via nmake or make in python? This seems like it could really slow down the builds. > > This brings up a 2nd question. I tried playing around with the makefiles that are autogenrated. I noticed I could do a clean, but the rebuild fails. Why is that? Is the top level makefile not used in the build process? > > Would it be possible to do the build step from python and without python and see what the speed difference is? I don't think nmake is parallel, but make supports parallel build. So it would be better to test with make vs. python. > > If python really is slowing down the build, we could have C code to invoke the python and then invoke the make commands in some form of parallelism. > > Andrew Fish > > > > > > On Mar 19, 2010, at 12:29 PM, Jim Buteau wrote: > > > Hello, > > My development team has been plagued by edk2 builds sporadically hanging. Our build environment is cygwin (1.5 and 1.7). Our python version is 2.5.2. When the hang occurs the windows task manager shows a make.exe process apparently stuck as indicated by its cpu usage. After much experimentation I have learned/concluded the following > > - The hung task was spawned in LaunchCommand(Command, WorkingDir) with the following python line: > Proc = Popen(Command, stdout=PIPE, stderr=PIPE, env=os.environ, cwd=WorkingDir, bufsize=-1) > > - The subsequent call to Proc.wait() never returns. > > - The use of Proc.wait() is somewhat troubling given the following (from http://docs.python.org/library/subprocess.html) > Warning > This will deadlock if the child process generates enough output to a stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that. > > > - Attempts to replace the wait() call with poll() or communicate() did not work for me. > > - Removing the I/O redirection appears to (after hundreds of multi-threaded builds) solve the hang problem. The popen() call was changed to > Proc = Popen(Command, env=os.environ, cwd=WorkingDir, bufsize=-1) > The threads created to read the Proc stdout and stderr pipes were removed. In this solution stdout and stderr from make go directly to the console instead of passing through EdkLogger. Given the alleviation of our hang problem, this is acceptable to us. > > Is this problem known by others? Can it be solved without removing the output redirection? > > Thanks, > Jim Buteau > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > edk2-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-devel > |
|
From: Lu, K. <ke...@in...> - 2010-03-20 02:46:50
|
Hi, Andrew:
I have a question; you mentioned here is multi-process or multi-thread? Do you mean when you enable MUTIL_THREAD in Conf/target.txt or from build command?
The article you provide is a good investigation, and need a time to research….but I also find similar performance issue in wxPython environment. So personally, I almost give up use wxPython to write GUI but use C#/mono.
I like you idea about use C code for muti-threading building, but it make big different between OS, as your known, threading.Thread in python is really a very basic wrapper. Because threading implementation is very dependent OS’s API and usage. I think Our build tool need try *not* use OS dependent code, …
I guess the threading schedule cost which bring from muti-threading is much less than performance tuning which bring from multi-threading. So seems it is not much valuable for use C code to wrapper threading. Do you agree?
I notice you find a new issue, I want to confirm, do you mean after all make files are created, then you go to the folder of top makefile and type “nmake clean”, it does not work?
Thanks.
Best Regard
K
---------------------------
hear and you forget; see and you remember; do and you understand
________________________________
From: Andrew Fish [mailto:af...@ap...]
Sent: 2010年3月20日 6:17
To: edk...@li...
Subject: Re: [edk2-buildtools] [edk2] hang/deadlock with MultiThread build in build.py due to use of output pipes in popen() call
One of my coworkers point out this: http://www.dabeaz.com/python/GIL.pdf about how python runs threads very slow, and slows down on multicore systems.
So I guess I have to ask the question of why we have to wrap building the code via nmake or make in python? This seems like it could really slow down the builds.
This brings up a 2nd question. I tried playing around with the makefiles that are autogenrated. I noticed I could do a clean, but the rebuild fails. Why is that? Is the top level makefile not used in the build process?
Would it be possible to do the build step from python and without python and see what the speed difference is? I don't think nmake is parallel, but make supports parallel build. So it would be better to test with make vs. python.
If python really is slowing down the build, we could have C code to invoke the python and then invoke the make commands in some form of parallelism.
Andrew Fish
On Mar 19, 2010, at 12:29 PM, Jim Buteau wrote:
Hello,
My development team has been plagued by edk2 builds sporadically hanging. Our build environment is cygwin (1.5 and 1.7). Our python version is 2.5.2. When the hang occurs the windows task manager shows a make.exe process apparently stuck as indicated by its cpu usage. After much experimentation I have learned/concluded the following
- The hung task was spawned in LaunchCommand(Command, WorkingDir) with the following python line:
Proc = Popen(Command, stdout=PIPE, stderr=PIPE, env=os.environ, cwd=WorkingDir, bufsize=-1)
- The subsequent call to Proc.wait() never returns.
- The use of Proc.wait() is somewhat troubling given the following (from http://docs.python.org/library/subprocess.html)
Warning
This will deadlock if the child process generates enough output to a stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate()<http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate> to avoid that.
- Attempts to replace the wait() call with poll() or communicate() did not work for me.
- Removing the I/O redirection appears to (after hundreds of multi-threaded builds) solve the hang problem. The popen() call was changed to
Proc = Popen(Command, env=os.environ, cwd=WorkingDir, bufsize=-1)
The threads created to read the Proc stdout and stderr pipes were removed. In this solution stdout and stderr from make go directly to the console instead of passing through EdkLogger. Given the alleviation of our hang problem, this is acceptable to us.
Is this problem known by others? Can it be solved without removing the output redirection?
Thanks,
Jim Buteau
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev_______________________________________________
edk2-devel mailing list
edk...@li...
https://lists.sourceforge.net/lists/listinfo/edk2-devel
|
|
From: Andrew F. <af...@ap...> - 2010-03-19 22:17:01
|
One of my coworkers point out this: http://www.dabeaz.com/python/GIL.pdf about how python runs threads very slow, and slows down on multicore systems. So I guess I have to ask the question of why we have to wrap building the code via nmake or make in python? This seems like it could really slow down the builds. This brings up a 2nd question. I tried playing around with the makefiles that are autogenrated. I noticed I could do a clean, but the rebuild fails. Why is that? Is the top level makefile not used in the build process? Would it be possible to do the build step from python and without python and see what the speed difference is? I don't think nmake is parallel, but make supports parallel build. So it would be better to test with make vs. python. If python really is slowing down the build, we could have C code to invoke the python and then invoke the make commands in some form of parallelism. Andrew Fish On Mar 19, 2010, at 12:29 PM, Jim Buteau wrote: > Hello, > > My development team has been plagued by edk2 builds sporadically hanging. Our build environment is cygwin (1.5 and 1.7). Our python version is 2.5.2. When the hang occurs the windows task manager shows a make.exe process apparently stuck as indicated by its cpu usage. After much experimentation I have learned/concluded the following > > - The hung task was spawned in LaunchCommand(Command, WorkingDir) with the following python line: > Proc = Popen(Command, stdout=PIPE, stderr=PIPE, env=os.environ, cwd=WorkingDir, bufsize=-1) > > - The subsequent call to Proc.wait() never returns. > > - The use of Proc.wait() is somewhat troubling given the following (from http://docs.python.org/library/subprocess.html) > WarningThis will deadlock if the child process generates enough output to a stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that. > > - Attempts to replace the wait() call with poll() or communicate() did not work for me. > > - Removing the I/O redirection appears to (after hundreds of multi-threaded builds) solve the hang problem. The popen() call was changed to > Proc = Popen(Command, env=os.environ, cwd=WorkingDir, bufsize=-1) > The threads created to read the Proc stdout and stderr pipes were removed. In this solution stdout and stderr from make go directly to the console instead of passing through EdkLogger. Given the alleviation of our hang problem, this is acceptable to us. > > Is this problem known by others? Can it be solved without removing the output redirection? > > Thanks, > Jim Buteau > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > edk2-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-devel |
|
From: Jim B. <bu...@ap...> - 2010-03-19 21:56:16
|
[sorry - this was posted to edk2-devel before finding this list] Hello, My development team has been plagued by edk2 builds sporadically hanging. Our build environment is cygwin (1.5 and 1.7). Our python version is 2.5.2. When the hang occurs the windows task manager shows a make.exe process apparently stuck as indicated by its cpu usage. After much experimentation I have learned/concluded the following - The hung task was spawned in LaunchCommand(Command, WorkingDir) with the following python line: Proc = Popen(Command, stdout=PIPE, stderr=PIPE, env=os.environ, cwd=WorkingDir, bufsize=-1) - The subsequent call to Proc.wait() never returns. - The use of Proc.wait() is somewhat troubling given the following (from http://docs.python.org/library/subprocess.html) WarningThis will deadlock if the child process generates enough output to a stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that. - Attempts to replace the wait() call with poll() or communicate() did not work for me. - Removing the I/O redirection appears to (after hundreds of multi-threaded builds) solve the hang problem. The popen() call was changed to Proc = Popen(Command, env=os.environ, cwd=WorkingDir, bufsize=-1) The threads created to read the Proc stdout and stderr pipes were removed. In this solution stdout and stderr from make go directly to the console instead of passing through EdkLogger. Given the alleviation of our hang problem, this is acceptable to us. Is this problem known by others? Can it be solved without removing the output redirection? Thanks, Jim Buteau |
|
From: Andrew F. <af...@ap...> - 2010-03-19 18:45:58
|
I placed an _asm { int 3 }; in GenFw to debug a new feature I was adding and I noticed if I run the build normally I can source level debug, but If I try and exit the debugging session from Visual Studio the build locks up and the only thing I can do is kill the entire dos box.
I think in this case the tool hits another breakpoint and crashes. But given the tool exits I would not expect the build command to deadlock.
I'm not sure if this is related, but I've noticed strange long timeouts on OS X python on errors and seen hangs in cygwin that seem to happen in more normal cases.
Andrew Fish
|
|
From: Andrew F. <af...@ap...> - 2010-03-16 22:24:29
|
We have a project where the PCD entries have been moved into a separate file and then that file is included in the .DSC file for the build. It looks like updating a file included by the .DSC file is not detected by the dependency logic of the build and the older cached copy of the PCD setting is used. It seems logical that files included by the .DSC file should be part of the dependency check. Is this a bug? How hard would it be to fix? We can test the fix if you send a patch. Andrew Fish |
|
From: Gao, L. <lim...@in...> - 2010-03-02 03:09:32
|
Samer:
Yes, no such limitation is for OUTPUT directory, although DSC spec only recommends that OUTPUT_DIRECTORY path start with the system environment variable $(WORKSPACE). So, I have updated GenFds on BaseTools r1907. Please try again.
Thanks
Liming
________________________________
From: Sam...@De... [mailto:Sam...@De...]
Sent: 2010年3月2日 2:44
To: edk...@li...
Cc: edk...@li...
Subject: [edk2] GenFds update
All,
The following check in GenFds.py was added recently
if os.path.normcase (Options.outputDir).find(Workspace) != 0:
EdkLogger.error("GenFds", FILE_NOT_FOUND, "OutputDir doesn't exist in Workspace!")
Any reason why the output directory has to be in the workspace? I have a project configuration that requires the output directory to be outside the workspace, and everything was working fine until this recent change.
Thanks,
--Samer
|
|
From: Lu, K. <ke...@in...> - 2010-02-25 03:07:47
|
Hi, guys:
The UNIXGCC tool chain is setup by BaseTools/gcc/mingw-gcc-build.py, which will automatically download mingw-runtime/binutil/gcc and build/install them. The version of binutil is 2.18.50.0.5 in this script.
But we found binutil has a bug as [Bug binutils/1391] objcopy trashes PE executable when using "add-gnu-debuglink", so objcopy will crash the PE image if using -add-gnu-debuglink.
This issue has been fixed by binutil 2.19.51.0.13 (http://www.kernel.org/pub/linux/devel/binutils/release.binutils-2.19.51.0.13). But 13 version is a middle version in 2.19.51.0 series. So I would like change mingw-gcc-build.py to use 2.20.51.0.5, also binutil 2.20 is popular installed by default in many linux distribution such as ubuntu 8.10 later.
So if I check-in this change, you maybe need update UNIXGCC tool chain by using mingw-gcc-build.py. If you have any concern or issue, please let me know before my check-in.
Thanks.
Best Regard
K
---------------------------
hear and you forget; see and you remember; do and you understand
|
|
From: Andrew F. <af...@ap...> - 2010-02-23 20:13:37
|
Works better if I'm subscribed to the mailing list!
Andrew Fish
Begin forwarded message:
> From: Andrew Fish <af...@ap...>
> Date: February 23, 2010 12:08:45 PM PST
> To: edk...@li...
> Cc: edk...@li...
> Subject: [edk2] Tiano usage?
> Reply-To: edk...@li...
>
> I noticed that VolInfo was printing out Tiano Firmware Volume and not PI Firmware Volume.
>
> printf ("%s Tiano Firmware Volume FFS image info. Version %d.%d, %s\n",
> UTILITY_NAME,
> UTILITY_MAJOR_VERSION,
> UTILITY_MINOR_VERSION,
> __DATE__
> );
>
> It got me thinking that it would be a good idea form some one to scrub the edk2 and basetools code bases for the usage of the work Tiano and make sure it is correct. Lots of things Tiano have been superseded by things in the PI specification.
>
> Andrew Fish
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> edk2-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
|
|
From: Jordan J. <jlj...@gm...> - 2010-01-22 20:16:32
|
60 messages has been excluded from this view by a project administrator.
