linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "PaX Team" <pageexec@freemail.hu>
To: linuxppc-dev@lists.ozlabs.org,
	kernel-hardening@lists.openwall.com, keescook@chromium.org,
	re.emese@gmail.com,
	Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
	spender@grsecurity.net, mmarek@suse.com
Subject: Re: [PATCH 3/3] powerpc: enable support for GCC plugins
Date: Thu, 08 Dec 2016 15:42:50 +0100	[thread overview]
Message-ID: <5849716A.32374.136DAAC@pageexec.freemail.hu> (raw)
In-Reply-To: <20161206062800.21800-3-andrew.donnellan@au1.ibm.com>

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

  parent reply	other threads:[~2016-12-08 15:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06  6:27 [PATCH 1/3] gcc-plugins: fix definition of DISABLE_LATENT_ENTROPY_PLUGIN Andrew Donnellan
2016-12-06  6:27 ` [PATCH 2/3] powerpc: correctly disable latent entropy GCC plugin on prom_init.o Andrew Donnellan
2016-12-06  6:28 ` [PATCH 3/3] powerpc: enable support for GCC plugins Andrew Donnellan
2016-12-06 20:40   ` Kees Cook
2016-12-07  1:05     ` [kernel-hardening] " Andrew Donnellan
2016-12-06 21:25   ` Emese Revfy
2016-12-07  5:49     ` Andrew Donnellan
2016-12-07  5:45   ` Andrew Donnellan
2016-12-08 14:42   ` PaX Team [this message]
2016-12-08 18:06     ` Kees Cook
2016-12-09  2:48       ` Andrew Donnellan
2016-12-09 10:59         ` PaX Team
2017-01-27  5:52           ` Andrew Donnellan
2017-01-27  5:55             ` Andrew Donnellan
2017-02-06 20:37 ` [1/3] gcc-plugins: fix definition of DISABLE_LATENT_ENTROPY_PLUGIN Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5849716A.32374.136DAAC@pageexec.freemail.hu \
    --to=pageexec@freemail.hu \
    --cc=andrew.donnellan@au1.ibm.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mmarek@suse.com \
    --cc=re.emese@gmail.com \
    --cc=spender@grsecurity.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).