This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gas: parsing source lines containing macro args


   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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]