From: Nadav Amit Sent: November 13, 2018 at 5:55:34 PM GMT > To: Ingo Molnar <[email protected]> > Cc: Ingo Molnar <[email protected]>, Masahiro Yamada > <[email protected]>, Michal Marek <[email protected]>, > Thomas Gleixner <[email protected]>, Borislav Petkov <[email protected]>, H. > Peter Anvin <[email protected]>, X86 ML <[email protected]>, Linux Kbuild mailing > list <[email protected]>, LKML <[email protected]>, > Logan Gunthorpe <[email protected]> > Subject: Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros > > > From: Ingo Molnar > Sent: November 13, 2018 at 11:30:00 AM GMT >> To: Nadav Amit <[email protected]> >> Cc: Ingo Molnar <[email protected]>, Masahiro Yamada >> <[email protected]>, Michal Marek <[email protected]>, >> Thomas Gleixner <[email protected]>, Borislav Petkov <[email protected]>, H. >> Peter Anvin <[email protected]>, [email protected], [email protected], >> [email protected] >> Subject: Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros >> >> >> >> * Nadav Amit <[email protected]> wrote: >> >>> Introducing the use of asm macros in c-code broke distcc, since it only >>> sends the preprocessed source file. The solution is to break the >>> compilation into two separate phases of compilation and assembly, and >>> between the two concatanate the assembly macros and the compiled (yet >> >> s/concatenate >> >>> not assembled) source file. Since this is less efficient, this >>> compilation mode is only used when make is called with the "DISTCC=y" >>> parameter. >>> >>> Note that the assembly stage should also be distributed, if distcc is >>> configured using "CFLAGS=-DENABLE_REMOTE_ASSEMBLE". >> >> It's a bit sad that we regressed distcc performance … > > I don’t know what the actual impact is, but Logan, who reported the bug says > there is an alternative solution for when distcc-pump is used (which > presumably would have ~zero performance degradation). distcc is really > fragile IMHO - it’s enough that it finds what looks like two source files in > the compiler command arguments for it to fall back to local compilation. > > [ In this regard, the distcc-pump solution would *not* work if distcc is > built with support for distributed assembly, since it will consider the .s > file as a second source file. ] > >>> +# If distcc is used, then when an assembly macro files is needed, the >>> +# compilation stage and the assembly stage need to be separated. Providing >>> +# "DISTCC=y" option enables the separate compilation and assembly. >> >> Let's fix the various typos: >> >>> +# If distcc is used, and when assembly macro files are needed, the >>> +# compilation stage and the assembly stage needs to be separated. >>> +# Providing the "DISTCC=y" option enables separate compilation and >>> +# assembly. > > That’s grammar, not typos ;-) > > Sorry for that - I will fix it an send v2 (as well as the whitespace noise).
Just one question before I send v2, since I have second thoughts. Does it make sense to require the “DISTCC” make parameter, or should it be set in the Kconfig? It can be detected automatically, the same way gcc/clang are detected or manually through a config option.
