This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

broken macro argument separation


This piece of code

.macro m arg1 arg2=0
	.long	\arg1, \arg2
.endm

_start:
	m	1-2+3
	m	1 -2+3
	m	1-2 +3
	m	1 -2 +3

produces on x86

   1              	.macro m arg1 arg2=0
   2              		.long	\arg1, \arg2
   3              	.endm
   4              	
   5              	_start:
   6              		m	1-2+3
   6 0000 02000000 	> .long 1-2+3,0
   6      00000000 
   7              		m	1 -2+3
   7 0008 01000000 	> .long 1,-2+3
   7      01000000 
   8              		m	1-2 +3
   8 0010 02000000 	> .long 1-2+3,0
   8      00000000 
   9              		m	1 -2 +3
   9 0018 01000000 	> .long 1,-2+3
   9      01000000 

i.e. white space between a number and '-' is retained while white
space between a number and '+' isn't.

Apart from leaving this as inconsistent as it is, there are a number
of possible solutions to this, all of which quite possibly breaking
existing code (I'm certain it would e.g. break the x86 Linux kernel
build).

The first solution would be to simply add '+' to i386's
extra_symbol_chars[]. The drawbacks would be that the
misbehavior would potentially remain on other architectures
(didn't check globally), and that other characters may have
similar issues ('.' for example, except that it's not expected to be
used in current gas expressions).

A second possibility would be to consider add all operator
characters to symbol_chars[]. I'm not certain what would break
in that case, but I can't imagine this to work without regressions.

A third possibility would be to treat macro arguments specially in
the scrubber. This is because currently there appear to be
assumptions that operands seen would always constitute
expressions, which for macro arguments simply doesn't have to
be true (a macro argument may e.g. simply be an operator).
This would seem the most compatible adjustment (expecting the
Linux kernel build to break nevertheless), with the downside of
requiring interaction between the scrubber and the macro
handling code.

The whole situation is made worse by the fact that even if one
intends to use commas to separate macro arguments, one has
no way to tell the assembler to only consider commas to be
separators here. Having to wrap macro arguments into double
quotes is also not very nice a solution, especially not when
preprocessing assembly sources with cpp (as is frequently the
case).

Suggestions/opinions anyone?

Thanks, Jan


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