Until at least 2.15 as accepted a macro like this: .macro foo size,arg,arg2 move\size \arg,\arg2 .endm foo.l %d0,%d1 Sometimes after that the syntax changed to include the dot into the name and this breaks code that was working nicely before. The Linux/m68k uses the macro like this. Currently I use this simple patch to work around the problem: diff -u -p -r1.44 macro.c --- macro.c 7 Jun 2006 11:27:57 -0000 1.44 +++ macro.c 26 Jun 2006 22:07:33 -0000 @@ -1202,7 +1202,7 @@ check_macro (const char *line, sb *expan return 0; s = line + 1; - while (is_part_of_name (*s)) + while (is_part_of_name (*s) && *s != '.') ++s; if (is_name_ender (*s)) ++s; Another alternative is to restore the old behaviour, which only accepts alphanumeric characters and '_'/'$'.
Subject: Re: New: macro name syntax changed Hi Zippel, > Until at least 2.15 as accepted a macro like this: > > .macro foo size,arg,arg2 > move\size \arg,\arg2 > .endm > > foo.l %d0,%d1 > Another alternative is to restore the old behaviour, which only accepts > alphanumeric characters and '_'/'$'. Wouldn't it be better to fix the sources that use this confusing form of macro invocation. Reading this as a programmer it looks to me like you are trying to use an opcode called "foo.l" and not a macro called "foo" whose first argument is ".l". ie wouldn't it be clearer to have: foo .l, %d0, %d1 Cheers Nick
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. The point is that gas broke compatibility here, so I can't provide such opcodes at all anymore.
Subject: Re: macro name syntax changed 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
Created attachment 1185 [details] Add new GAS command line switch --no-dot-in-macro-names
(In reply to comment #3) > 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. This is not possible, if it has to work with various versions of binutils. > 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. What's the point of making this "consistent"? At least for m68k the old rules made more sense and should be the default here.
BTW while looking through the source it may make sense to disable the dot completely on m68k as part of the name. It's not really valid as part of any symbol name, e.g. label.w has a special meaning. Although this would require a few more changes in the m68k parser, but it should mainly become simpler, e.g. it would make the extra look ahead in m68k-parse.y:yylex() unnecessary.
Even if "." isn't part of a name the macro is bad. The first argument (for size) becomes ".l $%d0" so the result would be "move.l%d0 %d1," after the usual whitespace removal.