AnsweredAssumed Answered

Building on multi-core PCs

Question asked by slin on Jan 22, 2013
Latest reply on Oct 14, 2013 by ColinJ

We have a relatively large mixed C & assembly Blackfin project that we build using our own Makefile system under cygwin (which calls the easmblkfn and ccblkfn assember & compiler from the VisualDSP++ toolchain).  When we just build with "make", everything works just fine.


Recently, however, in order to reduce build time on multi-core PCs, we've been experimenting with the "--jobs" option to gmake; this option allows make to spawn off multiple simultaneous compilations.  And when we do, we run into an interesting problem.  We see errors such as the following.


Here's one from the C compiler:


"..\common\pub\symbolnames.h", line 7: cc0005:  fatal error: could not open

          source file "modemsymbolnames.h"

  #include "modemsymbolnames.h"



And here's one from the assembler:

[Error ea1075] "AirInterface/TxDmaIsr.asm":50 'C:\temp\junk\RcEqualizer2.doj': Failed to process .IMPORT file.

        The compiled .IMPORT file could not be opened (elf_open failure).


That one is interesting because line 50 of the TxDmaIsr.asm file isn't trying to import the .doj object file, but rather contains this line:

    .import "RcEqualizer.h";



The specific place in the build process where these types of errors occur (and the specific files involved) vary from run to run.  But in each case, the compiler or assembler is complaining when trying to open a header file that is also used in other .c or .asm files.  Yes, of course the .h files exist!  Building without the --jobs option, or simply restarting the make with no other changes, results in a successful compilation.  Nothing fancy like dynamic generation of the .h files from earlier steps in the make process or anything.


Offhand, to me, one guess is that the compiler/assembler locks the .h file as it processes it.  And if another assembler/compiler process is compiling a different .c or .asm file which happens to require the same .h file, that second assembler/compiler process is prevented from opening the .h file because of the read lock head by the first process.


Is that correct?  Do the compiler & assembler read-lock their input files and not allow other compiler/assembler processed to read the files at the same time?  If so, how would one work around this issue to allow the same .h files to be used simultaneously by multiple compiler/assembler processes?  Obviously one may not want to have multiple processes compiling the same .c file, but the .h header files should be able to be shared by multiple processes.


(This is using VisualDSP++ 5.0, update 7, targeting ADSP-BF561.)


Thanks for any help!

Steve Lin