Date: Fri, 9 Dec 2016 13:48:26 +1100 From: Andrew Donnellan <andrew.donnellan@....ibm.com> To: Kees Cook <keescook@...omium.org>, PaX Team <pageexec@...email.hu> Cc: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Emese Revfy <re.emese@...il.com>, LKML <linux-kernel@...r.kernel.org>, linux-kbuild <linux-kbuild@...r.kernel.org>, Brad Spengler <spender@...ecurity.net>, Michal Marek <mmarek@...e.com> Subject: Re: [PATCH 3/3] powerpc: enable support for GCC plugins On 09/12/16 05:06, Kees Cook wrote: >> 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. I think I agree in principle - Makefiles are already unreadable enough without a million special cases. >> 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). If someone else is willing to write up that advice, then great. >> 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, We can't build without tm.h: http://pastebin.com/W0azfCr0 And we get warnings without c-common.h: http://pastebin.com/Aw8CAj10 >> 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. > > That is rather odd. What distro was the PPC test done on? (Or were > these manually built gcc versions?) These were all manually built using a script running on a Debian box. Installing precompiled distro versions of rather old gccs would have been somewhat challenging. I've just rebuilt 4.6.4 to double check that I wasn't just seeing things, but it seems that it definitely is still putting c-common.h in the old location. -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnellan@....ibm.com IBM Australia Limited
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.