linux-kernel - gas 2.16 and assembly macros -- entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Sep 2010 17:26:13 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jan Beulich <JBeulich@...ell.com>
CC:	Ingo Molnar <mingo@...e.hu>, heukelum@...tmail.fm,
	tglx@...utronix.de, akpm@...ux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: gas 2.16 and assembly macros -- entry_64.S build failure

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/