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
prev parent 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