From: "H. Peter Anvin" <hpa@zytor.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: Ingo Molnar <mingo@elte.hu>,
heukelum@fastmail.fm, tglx@linutronix.de,
akpm@linux-foundation.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: gas 2.16 and assembly macros -- entry_64.S build failure
Date: Fri, 01 Oct 2010 08:21:58 -0700 [thread overview]
Message-ID: <4CA5FC96.1030300@zytor.com> (raw)
In-Reply-To: <4CA5B7910200007800019F50@vpn.id2.novell.com>
On 10/01/2010 01:27 AM, Jan Beulich wrote:
>>>> On 01.10.10 at 02:26, "H. Peter Anvin" <hpa@zytor.com> wrote:
>> ... but that doesn't work with the macros like movq_cfi. On those, we
>
> Is that only because of the register names used as operands to
> movq_cfi etc not having the % specified right away? I don't think
> that is really needed, i.e. the % could go there rather than being
> added in the macro body - the .cfi_* directives are perfectly happy
> with having the prefix there (and I don't know why it was coded
> this way in the first place, as this made it less similar to the plain
> movq while I thought the goal was to keep the differences to a
> minimum).
>
No, and in fact the problem that spurred this discussion was in the use
of immediates, not registers:
pushq_cfi $(USER_DS)
Obviously we can't add the % register prefix, since pushq can take
either a register or an immediate (or, for that matter, a memory operand).
>> 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...
>
> The other alternative, albeit disliked by Ingo, continues to be to use
> __stringify() on all non-trivial operands, which then wouldn't require
> suppressing CONFIG_AS_CFI for pre-2.17 binutils.
You should be taken out and shot for even thinking that, never mind
putting it in writing...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2010-10-01 15:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 20:39 + arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch added to -mm tree akpm
[not found] ` <4C91F07E0200007800016B50@vpn.id2.novell.com>
[not found] ` <20100916082816.GA25681@elte.hu>
[not found] ` <4C91F3A30200007800016B64@vpn.id2.novell.com>
[not found] ` <20100916101355.GA31458@elte.hu>
[not found] ` <4C9219BC0200007800016C53@vpn.id2.novell.com>
2010-10-01 0:26 ` gas 2.16 and assembly macros -- entry_64.S build failure H. Peter Anvin
2010-10-01 1:01 ` Andrew Morton
2010-10-01 1:48 ` H. Peter Anvin
2010-10-01 8:27 ` Jan Beulich
2010-10-01 15:21 ` H. Peter Anvin [this message]
2010-10-01 15:46 ` Jan Beulich
2010-10-01 17:21 ` H. Peter Anvin
2010-10-04 7:36 ` Jan Beulich
2010-10-04 10:04 ` Avi Kivity
2010-10-04 15:43 ` H. Peter Anvin
2010-10-04 16:20 ` Avi Kivity
2010-10-04 18:23 ` H. Peter Anvin
2010-10-05 7:48 ` Avi Kivity
2010-10-05 7:51 ` Ingo Molnar
2010-10-05 9:09 ` Avi Kivity
2010-10-19 10:13 ` Jan Beulich
2010-10-19 10:32 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CA5FC96.1030300@zytor.com \
--to=hpa@zytor.com \
--cc=JBeulich@novell.com \
--cc=akpm@linux-foundation.org \
--cc=heukelum@fastmail.fm \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.