From: Jakob B. <jb...@wi...> - 2010-10-13 17:36:31
|
On 13-10-2010 06:15, anonymous coward wrote: >> The .asm file is generated by the makefile just before invoking nasm >> ... >> Yeah, but in this case it IS the exact same .asm file and nasm binary >> that failed a few seconds or minutes before, which makes me wonder >> what could induce nasm to behave differently. > > Does your build system ensure serialization between the Perl script > that generates the .asm file and the invocation of the NASM binary? > Yep, that was it! Now I have to figure out how to make the upstream build system (not my own), ensure the perl run does not exit until it is done writing the file. This is a classic non-parallel makefile system, so this really shouldn't have happened, but it did. > Another possibility is bad buffering, i.e. NASM invoked immediately > may see a partial .asm file (not from disk, but a memory buffer), but > NASM invoked a little later may see the proper .asm file (from disk). > Equally possible, given the circumstances above. > You could try to replace the NASM binary with e.g. cat, to show the > content of the .asm file. Though... if that doesn't show a partial .asm > file, then you might need to "work your way backwards" by building a > custom NASM binary that prints out every input line. (Of course that > might change buffering enough to hide/avoid the problem.) I tried that (with a custom clone of cat, since cat is not a standard binary on Windows and a ported cat would barf at the other commandline args anyway), and it showed that the .asm file was either empty or missing when "nasm.exe" started. Thanks for the help Jakob Bohm |