All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Avi Kivity <avi@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Jan Beulich <JBeulich@novell.com>,
	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: Tue, 5 Oct 2010 09:51:07 +0200	[thread overview]
Message-ID: <20101005075107.GC23608@elte.hu> (raw)
In-Reply-To: <4CAAD85B.7020607@redhat.com>


* Avi Kivity <avi@redhat.com> wrote:

>  On 10/04/2010 08:23 PM, H. Peter Anvin wrote:
> >On 10/04/2010 09:20 AM, Avi Kivity wrote:
> >>    On 10/04/2010 05:43 PM, H. Peter Anvin wrote:
> >>>  On 10/04/2010 03:04 AM, Avi Kivity wrote:
> >>>>    On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
> >>>>>   ... 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!)
> >>>>
> >>>>   Likely due to the fact that a minus sign can later join with a number
> >>>>   and become a new token, but a plug sign cannot.
> >>>>
> >>>
> >>>  ... except the same thing applies to other operators, other than the
> >>>  plus sign.  This kind of characterization is insanely frustrating, and
> >>>  really doesn't seem to follow logical rules ... we had a previous one
> >>>  where changing a macro name from upper case to lower case made gas 2.16
> >>>  work...
> >>>  	
> >>
> >>  Well, / and * do join.  % doesn't.  In a way, + does.
> >>
> >>  cpp is not a pure text processing language.  It's specifically geared to
> >>  C, and is fairly creaky when applying it to something other than C (and
> >>  is only somewhat creaky when applying it to C).
> >>
> >
> >The problem isn't with cpp, though, it's with gas.  There are bugs in
> >the gas 2.16 macro features that don't apply to any other gas version,
> >before *or* after.
> 
> I see.
> 
> I suppose it isn't possible to refuse to build with the broken version?

We could leave it build-broken and ask for a version specific quirk that 
runs a simple sed script over the source to turns 'pushl_cfi' et al into 
'push', or so?

Thanks,

	Ingo

  reply	other threads:[~2010-10-05  7:51 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
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 [this message]
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=20101005075107.GC23608@elte.hu \
    --to=mingo@elte.hu \
    --cc=JBeulich@novell.com \
    --cc=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=heukelum@fastmail.fm \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.