Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753986AbcLIBwt (ORCPT ); Thu, 8 Dec 2016 20:52:49 -0500 Received: from mail-ua0-f195.google.com ([209.85.217.195]:36016 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753144AbcLIBwr (ORCPT ); Thu, 8 Dec 2016 20:52:47 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Paul Gortmaker Date: Thu, 8 Dec 2016 20:52:15 -0500 X-Google-Sender-Auth: 2P1z044jZMShOrpeede9B6lDM2s Message-ID: Subject: Re: enabling COMPILE_TEST support for GCC plugins in v4.11 To: Kees Cook Cc: Stephen Rothwell , Arnd Bergmann , Randy Dunlap , Olof Johansson , Mark Brown , info@kernelci.org, Linus Torvalds , Andrew Morton , Will Deacon , Russell King - ARM Linux , LKML , Linux-Next , Fengguang Wu , Andrew Donnellan , Michael Ellerman , Laura Abbott , "x86@kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2830 Lines: 66 On Thu, Dec 8, 2016 at 2:00 PM, Kees Cook wrote: > Hi, > > I'd like to get the GCC plugins building under > allyesconfig/allmodconfig for -next soon (with the intention of > landing the change in v4.11). Specifically, I intend to revert > a519167e753e ("gcc-plugins: disable under COMPILE_TEST"). If I recall correctly, I noted that the plugins broke the kernel.org cross compiler toolchains which led to the above disable. Has that changed? People who have been doing tree wide changes and have been compiling across a bunch of different arch to ensure their changes don't cause breakage should not be left out in the cold. If there are newer toolchains that I can download and use in "toaster" mode, then great. But I (and many others) don't want to waste a day trying to make the latest gcc build some obsolete pa-risc architecture just to support a Kconfig default setting change. Can you elaborate on the motivation for this change? At the moment I see more downsides than advantages. Thanks, Paul. -- > > Right now the plugins are only supported on x86, arm, and arm64, > though powerpc may happen in either v4.10 or v4.11 as well. This means > that the autobuilders for these architectures need to have the "gcc > plugin development" package installed which contains the GCC headers > needed for the plugins. For Debian/Ubuntu, this is gcc-$N-plugin-dev > (and for cross compilers: gcc-$N-plugin-dev-$arch-linux-$abi). For > Fedora, it is gcc-plugin-devel (though I'm not sure the naming for > cross compilers). Manual builds of compilers should already have these > headers installed. > > The "noisy" plugin, cyc_complexity, is just an example, and I have > disabled it (which is pending[1] for v4.10). The remaining ones > (sancov and latent_entropy) are what I'm hoping to see tested > tree-wide (with the expectation that more are coming down the road: > initify, randstruct, structleak, constify, ...) > > IIUC, the 0day builder already has the headers installed. I tried to > look through linux-next to find all the other folks that do > autobuilding on these architectures; apologies if I've missed anyone. > > If you have a moment, applying 215e2aa6c024[1] and reverting > a519167e753e for an allyesconfig/allmodconfig build should let you > know if things are working correctly with headers installed. If anyone > sees any problems, please let me know and I can queue up fixes. > > Thanks! > > -Kees > > [1] http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=for-next/gcc-plugins&id=215e2aa6c024d27cdbe88e2ea88cb59dcab588eb > > -- > Kees Cook > Nexus Security > -- > To unsubscribe from this list: send the line "unsubscribe linux-next" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html