Re: [Nasm-users] nasm intermittently fails to assemble a file

[Frank K. <fbk...@zy...>]

Jakob Bohm wrote:

 > P.P.S
 > I am new to this list, hope my question is OK.

No. Too difficult. Take it away! :)

Seriously, welcome aboard, Jakob! I've cleared your "moderation" flag, 
so you should be able to post without delay, from now on. [hint: "reply 
all" to copy the list - just "reply" will reply only to me]

> Hi, I am having a strange problem with nasm, which has me somewhat
> baffled:

Me, too! Someone more knowledgeable is probably going to have to bail me 
out on this...

> When building a specific project (Openssl 1.0.0a for Win64-amd64),
> nasm 2.09.02 (and 2.08.02 and 2.08.01 too) fails to assemble one of the
> files (x86_64_cpuid.asm) when run on one build machine, but not the
> other.

So... what differs? Same build of Nasm? Same Perl?

I downloaded the source, but I can't find the file in question (or even 
the tmp32 directory). I deduce that this is built from 
crypto/x86_64cpuid.pl... perhaps with the assistance of 
crypto/perlasm/x86_64-xlate.pl and/or x86nasm.pl? Closest thing I see on 
my system (*old* Linux) after doing "make" is x86cpuid.s, which doesn't 
help. Can you give me a "dummies' guide" to creating this file? (or post 
it?)

Better yet(?), can you confirm that the .asm files on the "good" machine 
and the "bad" machine are identical?

> Strangely, manually running the same nasm command with the same values
> of all environment variables on the computer where it just failed,
> produces the correct output, but running the build script always fails
> on that same computer.

That makes it sound like the problem is external to Nasm, no?

> When nasm fails in that buildscript on that machine, it randomly
> chooses between two different failure modes:

I don't think Nasm includes a random number generator, so this too 
points to something other than Nasm - although I can't imagine what.

> A (most frequent): nasm reports success (no messages and 0 exit code),
> but the generated .obj file is empty (not 0-byte), containing no code,
> data or symbols, just a valid .obj file header (This obviously leads
> to a later linker error).
> 
> B (less frequent): nasm aborts claiming that all the local symbols
> are undefined.

Very strange, no matter what's doing it!!!

> On the other build machine, nasm just works as expected for the same
> files.

Yeah, that's what it's "supposed" to do... :)

> What could be causing this

Dunno.

> and how do I work around this?

If we figure out the first question, we might be able to figure out this 
one. I suppose "don't use that machine" isn't an option...

> P.S.
> The machine in question is an automated build server which has no
> trouble building millions of other lines of code (none of them with
> nasm though).  It runs Win2003 server (i386), cross compiling for
> multiple target architectures (including x86_64).

I'm paranoid enough to think that MS might introduce something that 
would cause random bugs in Nasm. Not paranoid enough to think it's very 
likely, though. :)

So we've got a 32-bit Nasm executable, assembling for "-f win64". That 
"shouldn't" be a problem...

> P.P.S
> I am new to this list, hope my question is OK.

Sure. I'm delighted to have a message I can approve (mostly, my job on 
this list is rejecting spam). I'm looking forward to a question I can 
actually answer!

> P.P.P.S
> The error messages when failing in mode B are:
> 
> 	nasm -f win64 -DNEAR -Ox -g -o tmp32\x86_64cpuid.obj
>                                                   tmp32\x86_64cpuid.asm
> (above is one long line wrapped for e-mail)

I can tell you that "-g" is being silently ignored. Shouldn't be a 
problem. You may want to leave it in, to be ready if/when we *do* add 
debug-info to the win32/win64 output formats.

> tmp32\x86_64cpuid.asm:5: error: symbol `OPENSSL_cpuid_setup' undefined

[snip more-of-same presumably from the same cause...]

> (The symbols in question are defined on lines before they are used, the
> errors report the lines where they are used).

Right. Defined as "extern" in the case of "OPENSSL_cpuid_setup" - just 
labels for the rest of 'em?

But other times, no errors but a "naked" header, right? Exact same .asm 
file, or a new Perl output?

Damn! I can't imagine what this could be, Jakob! I'm inclined to think 
"not a Nasm problem", but I'm not absolutely certain.

Anyone else (perhaps with Windows experience) got any ideas?

In any case, thanks for the feedback!

Best,
Frank