linux-kernel - Re: [PATCH] kbuild: work around distcc/icecc madness

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]

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/