A simple test program that demonstrates this problem: MOV r1, r0 LDR =garbage // no destination register MOV r2, r3 Assembles without any error or warning, and disassembles as: 00000000 <.text>: 0: e1a01000 mov r1, r0 4: e1a02003 mov r2, r3 The effect is the same if the "garbage" symbol is actually defined. I made this mistake while writing an IO routine, and had to look through the disassembly to figure out why the register had the wrong value. GAS should throw an error when it encounters such an instruction, since there is no sensible way to interpret it.
Created attachment 8290 [details] Proposed patch
Hi Solra, This was an interesting one. The problem is that "LDR = garbage" is a valid GAS operation - it sets a symbol called "LDR" to the value of an (undefined in this case) symbol called "garbage". Hence there was no warning message, and no LDR instruction in the output. Please could you try out the uploaded patch as a possible fix for this problem ? It makes the ARM port of GAS issue a warning message when the user attempts to create a symbol with the same name as an ARM instruction. One thing that I am not sure about is whether we need a command line option to suppress this warning, in the case that the user really does want to create a symbol that matches an instruction. Cheers Nick
Ah! That explains what's happening. Just tried the patch. It works great. As far as adding some way to suppress the warning... Instruction set extensions mean that an acceptable symbol one day will cause a warning tomorrow. Having some way to suppress the warning would be good. If it's possible, I'd suggest keeping the warning on definitions of the form "X=Y", and having no warning on the rather more explicit (but equivalent, right?) ".set X, Y". If the user really wants a symbol with that kind of name, they oughtn't mind being explicit about it.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8b2d793ce5ee03336d6c1d1f30b8d296cbe443de commit 8b2d793ce5ee03336d6c1d1f30b8d296cbe443de Author: Nick Clifton <nickc@redhat.com> Date: Thu Apr 30 11:17:55 2015 +0100 GAS ARM: Warn if the user creates a symbol with the same name as an instruction. PR gas/18347 gas * config/tc-arm.c (md_undefined_symbol): Issue a warning message (if enabled) when the user creates a symbol with the same name as an ARM instruction. (flag_warn_syms): New static variable. (arm_opts): Add mwarn-syms and mno-warn-syms. * doc/c-arm.texi (ARM Options): Document the -m[no-]warn-syms options. tests * gas/arm/pr18347.s: New file: Test case. * gas/arm/pr18347.l: New file: Expected assembler output. * gas/arm/pr18347.d: New file: Test driver.
Hi Solra, OK - I have enhanced the patch to add a new command line option to disable the warning (-mno-warn-sym). I have also added a testcase and some documentation. I did not make the check specific to the X=Y form as this would involve modifying generic code, and I wanted to keep this patch in the ARM backend. If this kind of problem turns up with other targets then I may reconsider this decision. Cheers Nick
Like I mentioned in the mailing list*, this warning should be restricted to <mnemonic> = <value> scenarios (and perhaps in future other possible similar scenarios where an instruction name can be misunderstood for a symbol name). * https://sourceware.org/ml/binutils/2015-05/msg00035.html
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ae8714c2712ef9a179cfa9158a289bd400c0ad97 commit ae8714c2712ef9a179cfa9158a289bd400c0ad97 Author: Nick Clifton <nickc@redhat.com> Date: Fri May 8 17:28:26 2015 +0100 Change ARM symbol name verification code so that it only triggers when the form "name = val" is used. PR gas/18347 * config/tc-arm.h (TC_EQUAL_IN_INSN): Define. * config/tc-arm.c (arm_tc_equal_in_insn): New function. Move the symbol name checking code to here from... (md_undefined_symbo): ... here.
Right. I have found a way to restrict the test so that it only triggers when the "name = val" form is used, and without having to modify generic code. I have updated the assembler testcase so that it includes several other varieties of symbol assignment using ARM instruction names, in order to make sure that these assignments do not trigger the warning. I have also run the ARM simulator testsuite and verified that this update fixes the problems with the label names used in some of the tests there. Cheers Nick This time it is right, it will work, and no one will have to get nailed to anything.
Thanks Nick.