gas 2.16 and assembly macros -- entry_64.S build failure

["H. Peter Anvin" <hpa@zytor.com>]

On 09/16/2010 04:21 AM, Jan Beulich wrote:
>>
>> Yes, to only generate CFI on binutils that allows us to write sane 
>> looking code.
>>
>> I.e. to disable CONFIG_AS_CFI on binutils that are broken for this.
> 
> Again - that won't help, as it's the macro invocation that gas
> fails one, not one of the actual .cfi_* directives.
> 

Looking again at this issue with the binutils version from hell
(sigh)... I'm running quickly out of ideas.

The problem is that cpp inserts spaces around expansions, so:

	pushq_cfi $(USER_DS)

... turns into something like ...

	pushq_cfi $( ( 5 * 8 + 3 ) )

... which these old versions of gas considers multiple arguments to the
macro, even though there is no comma anywhere.  We can defang *some* of
these problems by using cpp macros to kill them off:

#define pushq_cfi pushq

... but that doesn't work with the macros like movq_cfi.  On those, we
could argue that at least people won't put $ on them, but cpp will still
split them apart with spaces; this apparently causes problems at least
as soon as there is an expression more complicated than addition
involved (apparently plus signs are okay, but minus signs aren't!)

I'm completely lost about how to deal with this.   We can't simply
defang the macros -- at least not in a way that is likely to *stay*
working -- and dropping the macros is seriously going to impact the
debuggability of the kernel.  One way, of course, is to simply declare
binutils 2.16 and 2.15.9x (which is apparently included in
RHEL/CentOS 4) to be broken beyond repair unless distros backport a fix,
and in many ways I think that is the preferred option, but I don't know
if that makes sense to others...

	-hpa