This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Re: .macro behavior
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 28 Feb 2005 09:48:57 -0500 (EST)
- Subject: Re: [PATCH] Re: .macro behavior
- References: <s222dda9.071@emea1-mh.id2.novell.com>
On Mon, 28 Feb 2005, Jan Beulich wrote:
> This is a resubmission of the patch at
> http://sourceware.org/ml/binutils/2005-02/msg00120.html to address the
> inconsistent acceptance of identifiers between the macro handling code
> and
> the rest of the assembler, including the unability to use a macro the
> name
> of which starts with a dot.
> Over the previously submitted revisions, this has just cosmetic
> changes
> (NEWS entry, change to MMIX testcase removed again based on that
> target's
> maintainer's request) and thus I did not re-build or re-run the tests.
> +++ 2005-02-28/gas/NEWS 2005-02-28 09:52:47.000000000 +0100
> @@ -1,5 +1,11 @@
> -*- text -*-
>
> +* Macro names and macro parameter names can now be any identifier that
> would
> + also be legal as a symbol elsewhere. For macro parameter names, this
> is
> + known to cause problems in certain sources when the respective
> target uses
> + characters inconsistently (like MMIX's use of ':'), and thus macro
> + parameter references are no longer recognized as such.
> +
No, thanks, I don't like MMIX being accused of being
"inconsistent" like that. It *is* consistent - all trailing
":"s are chopped off. I think I now remember why; it's not
really related to ":" as separating namespaces, but the main
reason is so I could run the binutils test-suite! Most tests
"unportably" assumes that ":" is a label delimiter and not part
of the label. Maybe I should insiste that tests be rewritten
and labels there be defined as "label .set ." :-)
And I still think there's greater benefit from keeping the
syntax of macro *parameter names* the same as today, something
like "[A-Za-z_][A-Za-z0-9_]+" and not dependent on the target
symbol character set. (Heh, saying :alpha: and :alnum: would
imply it's locale-dependent. I don't think we want *that*! ;-)
brgds, H-P