This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: gas: parsing source lines containing macro args
- To: aph at pasanda dot cygnus dot co dot uk
- Subject: Re: gas: parsing source lines containing macro args
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 8 Nov 1999 12:06:37 -0500
- CC: binutils at sourceware dot cygnus dot com
- References: <19991108165120.1513.qmail@pasanda.cygnus.co.uk>
Date: 8 Nov 1999 16:51:20 -0000
From: Andrew Haley <aph@pasanda.cygnus.co.uk>
Consider a source file that looks like this:
-----------------------------------------------------------------------
.macro foo_macro arg0, arg1
foo \arg0,\arg1,0
.endm
.vu
n1: foo_macro %r01,%r00
n2: foo %r01,%r00,0
-----------------------------------------------------------------------
Line n1 expands to "foo %r01,%r00,0", which is the same as line n2.
However, if there is another token on the line inside the macro, bad
things happen:
-----------------------------------------------------------------------
.macro foo_macro arg0, arg1
bar foo \arg0,\arg1,0
.endm
.vu
n1: foo_macro %r01,%r00
n2: bar foo %r01,%r00,0
-----------------------------------------------------------------------
Instead of being expanded to "bar foo %r01,%r00,0", line n1 is
expanded to "bar foo%r01,%r00,0": a space has disappeared. This
happens becase when gas is scanning Line n1, any spaces after the
second operand are ignored *unless* they occur immediately before an
operand character. Unfortunately, in this case the space in question
is immediately before a backslash, which is not an operand character,
so the space is dropped.
My patch fixes this by outputting a space when going from State 10
(after seeing whitespace in state 9) to State 3 (after second white on
line) iff the non-whitepsace character which caused the transition was
a backslash.
It seems to me that correct handling really depends upon what the
macro parameter expands into. If the parameter expands into something
which does not start with an operand character, then we do not want to
keep the space. In your example, it expands into something which is
an operand character (at least, I guess it is, since otherwise the
space would have been dropped anyhow; on most platforms '%' is not an
operand char; on the i386 it is).
In other words, the problem seems to be that the scrubbing is being
done at the wrong level. We can't scrub correctly until after we have
expanded the macro.
However, that would be a real pain to fix.
I think your patch is OK, provided the current testsuite passes. But
I think your comment should be changed to indicate that we don't
actually have enough information to make the right choice, and that we
are making the choice which is more likely to be correct.
Ian