| 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
| ||
|
Message-ID: <20110310085900.GA25318@elte.hu> Date: Thu, 10 Mar 2011 09:59:00 +0100 From: Ingo Molnar <mingo@...e.hu> To: Michal Marek <mmarek@...e.cz> Cc: "H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, linux-kbuild <linux-kbuild@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: RFC: x86: kill binutils 2.16.x? * Michal Marek <mmarek@...e.cz> wrote: > On 3.3.2011 09:30, Ingo Molnar wrote: > > * H. Peter Anvin <hpa@...or.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@...ell.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@...ux-foundation.org> Signed-off-by: Jan Beulich <jbeulich@...ell.com> Cc: Shaohua Li <shaohua.li@...el.com> LKML-Reference: <4D6F81B10200007800034B0B@....id2.novell.com> Signed-off-by: Ingo Molnar <mingo@...e.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 -- 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/
Powered by blists - more mailing lists