All of lore.kernel.org
 help / color / mirror / Atom feed
From: paul.gortmaker@windriver.com (Paul Gortmaker)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dont specify STACKPROTECTOR in defconfigs
Date: Thu, 21 Jul 2016 14:04:37 -0400	[thread overview]
Message-ID: <20160721180437.GE21225@windriver.com> (raw)
In-Reply-To: <CACPK8XfRFPxr6NbaMBztNCrOnGUkFaAiE+op+Mxyqk7de4_2ng@mail.gmail.com>

[Re: [PATCH] ARM: dont specify STACKPROTECTOR in defconfigs] On 22/07/2016 (Fri 01:40) Joel Stanley wrote:

> Hi Paul,
> 
> On Fri, Jul 22, 2016 at 12:41 AM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
> > Note the output from the following:
> >
> >    $ git grep STACKPROTECTOR arch/arm/configs/
> >    arch/arm/configs/aspeed_g4_defconfig:CONFIG_CC_STACKPROTECTOR_STRONG=y
> >    arch/arm/configs/aspeed_g5_defconfig:CONFIG_CC_STACKPROTECTOR_STRONG=y
> >    arch/arm/configs/bcm2835_defconfig:CONFIG_CC_STACKPROTECTOR_REGULAR=y
> >    $
> >
> > Only three defconfigs specify a value.  And two of the three ask for
> > the strong variant, which isn't supported by older toolchains.
> >
> > Due to the nature of ARM having more platform specific code than say
> > x86, the allyesconfig and allmodconfig aren't as effective for build
> > coverage.  So, in addition, I like to use a trivial script to walk all
> > the defconfigs and build each one.
> >
> > However I will get false positives on unsupported stackprotector values
> > with an older toolchain like gcc-4.6.3.  As in this instance I am just
> > using the compiler as a glorified syntax checker on a machine where I
> > build a bunch of other arch for the same reason, there is no real
> > motivation to get a newer toolchain for improved optimization etc.
> 
> I'm happy to remove it from the Aspeed configurations as I'm not sure
> why it was enabled in the first place.
> 
> However, I do not agree with the reasoning here. If you're building to
> check syntax a modern GCC will certainly pick up on more than one from
> four years ago.

Just to clarify, syntax in this case is just for fat fingered typos and
ensuring functions resolve with the appropriate header includes.  If I
was coding new stuff specifically for ARM, then that would be different.

> 
> > Since there are only three of them, and there is nothing about these
> > settings that are board/platform specific, I propose we just eliminate
> > the three existing instances and take the default.
> 
> This makes sense to me.
> 
> Acked-by: Joel Stanley <joel@jms.id.au>

Thanks,
Paul.
--

WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Joel Stanley <joel@jms.id.au>
Cc: <linux-kernel@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Lee Jones <lee@kernel.org>, Eric Anholt <eric@anholt.net>,
	<linux-arm-kernel@lists.infradead.org>,
	<bcm-kernel-feedback-list@broadcom.com>
Subject: Re: [PATCH] ARM: dont specify STACKPROTECTOR in defconfigs
Date: Thu, 21 Jul 2016 14:04:37 -0400	[thread overview]
Message-ID: <20160721180437.GE21225@windriver.com> (raw)
In-Reply-To: <CACPK8XfRFPxr6NbaMBztNCrOnGUkFaAiE+op+Mxyqk7de4_2ng@mail.gmail.com>

[Re: [PATCH] ARM: dont specify STACKPROTECTOR in defconfigs] On 22/07/2016 (Fri 01:40) Joel Stanley wrote:

> Hi Paul,
> 
> On Fri, Jul 22, 2016 at 12:41 AM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
> > Note the output from the following:
> >
> >    $ git grep STACKPROTECTOR arch/arm/configs/
> >    arch/arm/configs/aspeed_g4_defconfig:CONFIG_CC_STACKPROTECTOR_STRONG=y
> >    arch/arm/configs/aspeed_g5_defconfig:CONFIG_CC_STACKPROTECTOR_STRONG=y
> >    arch/arm/configs/bcm2835_defconfig:CONFIG_CC_STACKPROTECTOR_REGULAR=y
> >    $
> >
> > Only three defconfigs specify a value.  And two of the three ask for
> > the strong variant, which isn't supported by older toolchains.
> >
> > Due to the nature of ARM having more platform specific code than say
> > x86, the allyesconfig and allmodconfig aren't as effective for build
> > coverage.  So, in addition, I like to use a trivial script to walk all
> > the defconfigs and build each one.
> >
> > However I will get false positives on unsupported stackprotector values
> > with an older toolchain like gcc-4.6.3.  As in this instance I am just
> > using the compiler as a glorified syntax checker on a machine where I
> > build a bunch of other arch for the same reason, there is no real
> > motivation to get a newer toolchain for improved optimization etc.
> 
> I'm happy to remove it from the Aspeed configurations as I'm not sure
> why it was enabled in the first place.
> 
> However, I do not agree with the reasoning here. If you're building to
> check syntax a modern GCC will certainly pick up on more than one from
> four years ago.

Just to clarify, syntax in this case is just for fat fingered typos and
ensuring functions resolve with the appropriate header includes.  If I
was coding new stuff specifically for ARM, then that would be different.

> 
> > Since there are only three of them, and there is nothing about these
> > settings that are board/platform specific, I propose we just eliminate
> > the three existing instances and take the default.
> 
> This makes sense to me.
> 
> Acked-by: Joel Stanley <joel@jms.id.au>

Thanks,
Paul.
--

  reply	other threads:[~2016-07-21 18:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21 15:11 [PATCH] ARM: dont specify STACKPROTECTOR in defconfigs Paul Gortmaker
2016-07-21 15:11 ` Paul Gortmaker
2016-07-21 15:23 ` Eric Anholt
2016-07-21 15:23   ` Eric Anholt
2016-07-21 16:10 ` Joel Stanley
2016-07-21 16:10   ` Joel Stanley
2016-07-21 18:04   ` Paul Gortmaker [this message]
2016-07-21 18:04     ` Paul Gortmaker

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=20160721180437.GE21225@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.