I'm using today's CVS gas: > ./gas/as-new --version GNU assembler 2.15.90 20040226 Copyright 2002 Free Software Foundation, Inc. [etc.] The errors I get are typically as follows: > ./gas/as-new /tmp/foo.s /tmp/foo.s: Assembler messages: /tmp/foo.s:7: Error: missing or invalid immediate expression `' taken as 0 /tmp/foo.s:7: Error: suffix or operands invalid for `mov' /tmp/foo.s:8: Error: missing or invalid immediate expression `' taken as 0 /tmp/foo.s:8: Error: suffix or operands invalid for `call' Here is the code: All it tries to do is call and take the address of a function called "byte". > cat /tmp/foo.s .intel_syntax .text byte: RET foo: MOV EAX, OFFSET byte CALL byte RET ------------------ You can get similar bad behavior by replacing byte with any of: (word dword xword offset mov ret call).
Reproduced.
I believe the reason you're witnessing this behaviour is (quoting from node `i386-Syntax' of the GAS manual): * In AT&T syntax the size of memory operands is determined from the last character of the instruction mnemonic. Mnemonic suffixes of `b', `w', `l' and `q' specify byte (8-bit), word (16-bit), long (32-bit) and quadruple word (64-bit) memory references. Intel syntax accomplishes this by prefixing memory operands (_not_ the instruction mnemonics) with `byte ptr', `word ptr', `dword ptr' and `qword ptr'. Thus, Intel `mov al, byte ptr FOO' is `movb FOO, %al' in AT&T syntax. In the case of the CALL instruction you gave, "CALL byte" is ambiguous. The assembler is expecting something else after "byte", not finding it and assuming a memory operand value of zero: foo.s:7: Error: missing or invalid immediate expression `' taken as 0 While the error message is not perfect, I think you're violating the Intel syntax. Do you agree? Cheers, Ben
Yeah, after having looked at this more closely, there's no good way to call a symbol named "byte" in Intel syntax. You simply have to avoid using reserved words as symbols. I guess that having a better error message would be nice, but I must now admit that I don't have the time to submit a patch for a better error message (sorry!) Here's where the discussion trailed off... http://mail.gnu.org/archive/html/bug-binutils/2004-03/msg00012.html http://mail.gnu.org/archive/html/bug-binutils/2004-03/msg00007.html http://mail.gnu.org/archive/html/bug-binutils/2004-03/msg00010.html Feel free to close this as 'INVALID' if you see fit. Thanks for bugging me about it.
Originator agrees that the PR can be closed.