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: <20090320193334.GA19501@elte.hu>
Date:	Fri, 20 Mar 2009 20:33:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Thomas Gleixner <tglx@...utronix.de>
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


* Thomas Gleixner <tglx@...utronix.de> wrote:

> 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".

as in "did not fail the build" :-)

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

i dont do anything weird. i use:

CROSS_COMPILE='distcc 
/opt/crosstool/gcc-4.2.2-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-'

host compiler was never supposed to be the same in terms of 
capability as target compiler.

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