public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Michal Marek <mmarek@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: RFC: x86: kill binutils 2.16.x?
Date: Thu, 10 Mar 2011 09:59:00 +0100	[thread overview]
Message-ID: <20110310085900.GA25318@elte.hu> (raw)
In-Reply-To: <4D7890CE.60800@suse.cz>


* Michal Marek <mmarek@suse.cz> wrote:

> On 3.3.2011 09:30, Ingo Molnar wrote:
> > * H. Peter Anvin <hpa@zytor.com> wrote:
> >> kbuild people: is there a way to test for a specific assembler version
> >> in Kbuild (and error out the build for it?)
> > 
> > Could we add a testcase for one of the more egregious breakages and bail out then? 
> > That way we don't have to get the version information right - broken prereleases 
> > would be covered as well.
> > 
> > For example this sequence:
> > 
> > .irp idx,0,1,2
> > .if 0 > \idx
> > .endif
> > .endr
> >
> > Will break on 2.16, right? It builds fine on 2.20.
> 
> This seems to work for me with the binutils version from sles10 (even
> with a vanilla build of binutils):
> $ as -v <<EOF; echo $?
> > .irp idx,0,1,2
> > .if 0 > \idx
> > .endif
> > .endr
> > EOF
> GNU assembler version 2.16.91.0.5 (i586-suse-linux) using BFD version
> 2.16.91.0.5 20051219
> 0
> $
> 
> So either the bug is fixed in that version already or you picked a wrong
> example (or I did not understand what should fail here). But don't get
> me wrong, I'm all for checking for actual bugs instead of innocent
> version strings.

I cited an incorrect testcase most likely. Note that Jan was able to work around the 
limitations in 2.16 after all - see the workaround commit that i have queued up in 
x86/mm, attached below.

Thanks,

	Ingo

--------------->
>From d04c579f971bf7d995db1ef7a7161c0143068859 Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich@novell.com>
Date: Thu, 3 Mar 2011 10:55:29 +0000
Subject: [PATCH] x86: Work around old gas bug

Add extra parentheses around a couple of definitions introduced
by "x86: Cleanup vector usage" and used in assembly macro
arguments, and remove spaces. Without that old (2.16.1) gas
would see more macro arguments than were actually specified.

Reported-and-tested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Shaohua Li <shaohua.li@intel.com>
LKML-Reference: <4D6F81B10200007800034B0B@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/include/asm/irq_vectors.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 4980f48..6e976ee 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -126,14 +126,14 @@
 
 /* up to 32 vectors used for spreading out TLB flushes: */
 #if NR_CPUS <= 32
-# define NUM_INVALIDATE_TLB_VECTORS NR_CPUS
+# define NUM_INVALIDATE_TLB_VECTORS	(NR_CPUS)
 #else
-# define NUM_INVALIDATE_TLB_VECTORS 32
+# define NUM_INVALIDATE_TLB_VECTORS	(32)
 #endif
 
-#define INVALIDATE_TLB_VECTOR_END	0xee
+#define INVALIDATE_TLB_VECTOR_END	(0xee)
 #define INVALIDATE_TLB_VECTOR_START	\
-	(INVALIDATE_TLB_VECTOR_END - NUM_INVALIDATE_TLB_VECTORS + 1)
+	(INVALIDATE_TLB_VECTOR_END-NUM_INVALIDATE_TLB_VECTORS+1)
 
 #define NR_VECTORS			 256
 

      reply	other threads:[~2011-03-10  8:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-02 18:15 RFC: x86: kill binutils 2.16.x? H. Peter Anvin
2011-03-02 20:03 ` Andrew Morton
2011-03-02 20:11   ` H. Peter Anvin
2011-03-02 20:25     ` Sam Ravnborg
2011-03-02 20:30       ` Randy Dunlap
2011-03-02 21:28     ` Vegard Nossum
2011-03-02 21:29       ` H. Peter Anvin
2011-03-02 20:54 ` Thomas Gleixner
2011-03-02 21:02   ` H. Peter Anvin
2011-03-02 21:17     ` Thomas Gleixner
2011-03-02 22:59       ` H. Peter Anvin
2011-03-03  8:30         ` Ingo Molnar
2011-03-08 19:57           ` Kyle Moffett
2011-03-08 21:28             ` Benjamin Herrenschmidt
2011-03-08 21:56               ` Scott Wood
2011-03-08 21:59               ` Kyle Moffett
2011-03-08 23:13                 ` Benjamin Herrenschmidt
2011-03-08 23:43                   ` Kyle Moffett
2011-03-09  4:39                 ` Segher Boessenkool
2011-03-10  8:50           ` Michal Marek
2011-03-10  8:59             ` Ingo Molnar [this message]

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=20110310085900.GA25318@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox