Date: Thu, 08 Dec 2016 15:42:50 +0100 From: "PaX Team" <pageexec@...email.hu> To: linuxppc-dev@...ts.ozlabs.org, kernel-hardening@...ts.openwall.com, keescook@...omium.org, re.emese@...il.com, Andrew Donnellan <andrew.donnellan@....ibm.com> CC: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org, spender@...ecurity.net, mmarek@...e.com Subject: Re: [PATCH 3/3] powerpc: enable support for GCC plugins On 6 Dec 2016 at 17:28, Andrew Donnellan wrote: > Enable support for GCC plugins on powerpc. > > Add an additional version check in gcc-plugins-check to advise users to > upgrade to gcc 5.2+ on powerpc to avoid issues with header files (gcc <= > 4.6) or missing copies of rs6000-cpus.def (4.8 to 5.1 on 64-bit targets). i don't think that this is the right approach. there's a general and a special issue here, both of which need different handling. the general problem is to detect problems related to gcc plugin headers and notify the users about solutions. emitting various messages from a Makefile is certainly not a scalable approach, just imagine how it will look when the other 30+ archs begin to add their own special cases... if anything, they should be documented in Documentation/gcc-plugins.txt (or a new doc if it grows too big) and the Makefile message should just point at it. as for the solutions, the general advice should enable the use of otherwise failing gcc versions instead of forcing updating to new ones (though the latter is advisable for other reasons but not everyone's in the position to do so easily). in my experience all one needs to do is manually install the missing files from the gcc sources (ideally distros would take care of it). the specific problem addressed here can (and IMHO should) be solved in another way: remove the inclusion of the offending headers in gcc-common.h as neither tm.h nor c-common.h are needed by existing plugins. for background, i created gcc-common.h to simplify plugin development across all supportable gcc versions i came across over the years, so it follows the 'everything but the kitchen sink' approach. that isn't necessarily what the kernel and other projects need so they should just use my version as a basis and fork/simplify it (even i maintain private forks of the public version). as for the location of c-common.h, upstream gcc moved it under c-family in 2010 after the release of 4.5, so it should be where gcc-common.h expects it and i'm not sure how it ended up at its old location for you. cheers, PaX Team
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.