gas: retain whitespace between strings

Macro arguments may be separated by commas or just whitespace. Macro
arguments may also be quoted (where one level of quotes is removed in
the course of determining the values for the respective formal
parameters). Furthermore this quote removal knows _two_ somewhat odd
escaping mechanisms: One, apparently in existence forever, is that a
pair of quotes counts as the escaping of a quote, with the pair being
transformed to a single quote in the course of quote removal. The other
(introduced by c06ae4f232e6) looks more usual on the surface in that it
deals with \" sequences, but it _retains_ the escaping \. Hence only the
former mechanism is suitable when the value to be used by the macro body
is to contain a quote. Yet this results in ambiguity of what "a""b" is
intended to mean; elsewhere (e.g. for .ascii) it represents two
successive string literals. However, in any event is the above different
from "a" "b": I don't think this can be viewed the same as "a""b" when
processing macro arguments.

Change the scrubber to retain such whitespace, by making the processing
of strings more similar to that of symbols. And indeed this appears to
make sense when taking into account that for quite a while gas has been
supporting quoted symbol names.

Taking a more general view, however, the change doesn't go quite far
enough. There are further cases where significant whitespace is removed
by the scrubber. The new testcase enumerates a few in its ".if 0"
section. I'm afraid the only way that I see to deal with this would be
to significantly simplify the scrubber, such that it wouldn't do much
more than collapse sequences of unquoted whitespace into a single blank.
To be honest problems in this area aren't really surprising when seeing
that there's hardly any checking of .macro use throughout the testsuite
(and in particular in the [relatively] generic tests under all/).

1 files changed, 21 insertions, 0 deletions

diff --git a/gas/doc/as.texi b/gas/doc/as.texi
index 55b3156..9a7db3f 100644
--- a/gas/doc/as.texi
+++ b/gas/doc/as.texi
@@ -6186,6 +6186,27 @@ Note: this problem of correctly identifying string parameters to pseudo ops
 also applies to the identifiers used in @code{.irp} (@pxref{Irp})
 and @code{.irpc} (@pxref{Irpc}) as well.
 
+Another issue can occur with the actual arguments passed during macro
+invocation: Multiple arguments can be separated by blanks or commas.  To have
+arguments actually contain blanks or commas (or potentially other non-alpha-
+numeric characters), individual arguments will need to be enclosed in either
+parentheses @code{()}, square brackets @code{[]}, or double quote @code{"}
+characters.  The latter may be the only viable option in certain situations,
+as only double quotes are actually stripped while establishing arguments.  It
+may be important to be aware of two escaping models used when processing such
+quoted argument strings: For one two adjacent double quotes represent a single
+double quote in the resulting argument, going along the lines of the stripping
+of the enclosing quotes.  But then double quotes can also be escaped by a
+backslash @code{\}, but this backslash will not be retained in the resulting
+actual argument as then seen / used while expanding the macro.
+
+As a consequence to the first of these escaping mechanisms two string literals
+intended to be representing separate macro arguments need to be separated by
+white space (or, better yet, by a comma).  To state it differently, such
+adjacent string literals - even if separated only by a blank - will not be
+concatenated when determining macro arguments, even if they're only separated
+by white space.  This is unlike certain other pseudo ops, e.g. @code{.ascii}.
+
 @item .endm
 @cindex @code{endm} directive
 Mark the end of a macro definition.