Re: Very interesting IA64 gas bug

[Jim Wilson <wilson at tuliptree dot org>]

I don't see any problem with the buffer itself.  However, there is a 
problem with the parsing algorithm in do_scrub_chars.

do_scrub_chars tries to eliminate whitespace between arguments.  It 
assumes that it is starting at the beginning of a line, and that a line 
looks like "label: opcode arguments" where label is optional.  IA-64 
instructions do not look like this, because we have qualifying 
predicates before the opcode, e.g. (p7).  This happens to work by 
accident with the current parsing code because ( and ) are not symbol 
characters, so do_scrub_chars assumes it is neither the label nor opcode 
and passes it through unchanged without changing state.

The problem occurs if a buffer ends in the middle of a qualifying 
predicate (qp).  The first buffer sees "(p" at the end, and because it 
is at the end of the buffer, it stops in the middle of the qp and 
switches to state 11 which means this may be a label.  When we start the 
next buffer, we switch to state 3 (after the opcode) because there was 
no colon.  The "hint" is then parsed as an argument, and we eliminate 
the space after it, and now we have an unknown opcode hint@pause.

This could be fixed by adding a new state for parsing IA-64 qps.  If we 
see an open paren before the opcode, then we switch to the new state, 
and switch back to state 0 after seeing the ).

Alternatively, we could give up and decide that do_scrub_chars can't 
know all details of all target assembler syntaxes, and hence shouldn't 
be trying to delete spaces between arguments.  It should only eliminate 
duplicate whitespace.  This would make porting to oddball targets 
slightly easier, and maintenance of do_scrub_chars easier.  It may 
require modifying some targets to handle whitespace in arguments though.

Jim