Hi Roman,
You read it correctly, the intention is to provide the opcodes
foo.b/foo.w/foo.l, so using "foo .l" would be even more confusing.
OK, so presumably a workaround is to provide individual macros with the
names "foo.b", "foo.w" and so on, rather than just one macro.
The point is that gas broke compatibility here, so I can't provide
> such opcodes at all anymore.
Hmm, well the change was to make macros names consistent with other
names. ie if string was a valid name for a (pseudo) opcode or a label,
then it could also be a valid name for a macro. I appreciate however
that this did break backwards compatibility. So please could you try
out the uploaded patch and let me know if it works for you. (You will
need to add the command line switch --no-dot-in-macro-names to assembler
command line).
Cheers
Nick
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
