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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0903202010250.29264@localhost.localdomain>
Date:	Fri, 20 Mar 2009 20:31:01 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Sam Ravnborg <sam@...nborg.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] kbuild: work around distcc/icecc madness

On Fri, 20 Mar 2009, Ingo Molnar wrote:
> 
> * Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > > > ---
> > > >  scripts/Kbuild.include |    5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > Doesnt fully work:
> > > 
> > > arch/x86/kernel/entry_32.S:346: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > arch/x86/kernel/entry_32.S:394: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > arch/x86/kernel/entry_32.S:519: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > arch/x86/kernel/entry_32.S:614: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > arch/x86/kernel/entry_32.S:685: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > arch/x86/kernel/entry_32.S:754: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > 
> > > config attached. Distcc driven build.
> > 
> > Same config works fine here. Do you have different 
> > compilers/binutils on your distcc cluster ? I tripped over this 
> > distcc feature in the past, that's why I have switched to iceccc.
> 
> the distcc binutils is different from the host build environment 
> binutils and compiler. This always worked fine - can we preserve it?

It depends what you define as "worked fine".

The point is that the CFI checks are done at compile time by checking
binutils. If you have two versions - one with and one without CFI
support - then it's just a question of luck which one is checked. So
in your case it might have worked because both distcc and your local
gcc agreed that CFI is not enabled, but the reason why the distcc
check for CFI fails is because it fails to handle the stdin input and
not because it does not support CFI.

So with my patch distcc gives you the correct answer, but now you trip
over the local binutils lack of CFI support.

I don't think that such a setup is something we need to preserve.

Thanks,

	tglx
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ