The opcode array iterator mechanism can, in some situations, result in
reading memory outside of the opcode array. When using the
iterator-next mechanism to find the next possible arc_opcode, if we find
an opcode where the name field is NULL, or the name does not match, then
the cached opcode pointer is not set to NULL. The result is that
another call to iterator-next will again increment the opcode
pointer (which might now point outside the opcode array) and attempt to
access the name field of this undefined opcode.
Fixed in this commit by clearing the cached opcode pointer.
I've added a test case, which currently shows the bug, however, this
will only expose this bug while the opcode used (dsp_fp_cmp) is the last
opcode in the table.
gas/ChangeLog:
* config/tc-arc.c (arc_opcode_hash_entry_iterator_next): Set
cached opcode to NULL when we reach a non-matching opcode.
* testsuite/gas/arc/asm-errors-2.d: New file.
* testsuite/gas/arc/asm-errors-2.err: New file.
* testsuite/gas/arc/asm-errors-2.s: New file.
fe779266b3