On Fri, Mar 17, 2017 at 7:57 PM, Borislav Petkov <bp@xxxxxxxxx> wrote: > On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote: >> This problem is more general and is not specific to clang. It equally >> applies to different versions of gcc, different arches and different >> configs (namely, anything else than what a developer used for >> testing). > > I guess. We do carry a bunch of gcc workarounds along with the cc-* > macros in scripts/Kbuild.include. > >> A known, reasonably well working solution to this problem is >> a system of try bots that test patches before commit with different >> compilers/configs/archs. We already have such system in the form of >> 0-day bots. It would be useful to extend it with clang as soon as >> kernel builds. > > Has someone actually already talked to Fengguang about it? +Fengguang > Oh, and the stupid question: why the effort to build the kernel > with clang at all? Just because or are there some actual, palpable > advantages? On our side it is: - clang make it possible to implement KMSAN (dynamic detection of uses of uninit memory) - better code coverage for fuzzing - why simpler and faster development (e.g. we can port our user-space hardening technologies -- CFI and SafeStack) You can also find some reasons in the Why section of LLVM-Linux project: http://llvm.linuxfoundation.org/index.php/Main_Page -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
