CONFIG_CC_STACKPROTECTOR v. armhf v3.13 mainline builds

[Kamal Mostafa]

Okay, I've resolved half of this puzzle ...

On Wed, 2015-12-09 at 10:35 -0800, Kamal Mostafa wrote:
>         Subject:	Mainline Build v3.13.11-ckt31 failed
> The armhf build[0] failed with:
>         
>         /home/kernel/COD/linux/arch/arm/boot/compressed/atags_to_fdt.c:96: undefined reference to `__stack_chk_fail'
>         /home/kernel/COD/linux/arch/arm/boot/compressed/atags_to_fdt.c:96: undefined reference to `__stack_chk_guard'


There's some broken logic in 3.13's arch/arm/Makefile around the use of
-fstack-protector.  Trusty carries a SAUCE patch specifically to avoid
this problem (thanks henrix!):

        900be9e UBUNTU: SAUCE: disable stack-protector for ARM compressed bootloader


Mainline fixed the broken arch/arm/Makefile logic, inadvertently maybe,
in 3.14 in the second of these two commits (thanks rtg!):

        8779657 stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG
        19952a9 stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures

Backporting those to 3.13-stable fixes my build failure, and adds
support for CONFIG_CC_STACKPROTECTOR_{NONE,REGULAR,STRONG} for compilers
that support those.  I intend to apply them in the next 3.13-stable
release.  (And following that, the SAUCE patch can be reverted from
Trusty).


I still do not understand the second part of the puzzle -- why the
builder only now started noticing this failure:

> But what's really weird is, when I go look at the previous 3.13 mainline
> armhf build logs, I see that that error has ALWAYS been present[1]
> despite the "all's well" emails!
> 
> Did the mainline builder somehow just recently gain the ability to
> notice this failure?
> 
> [0]
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt31-trusty/BUILD.LOG.armhf
> 
> [1]
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt12-trusty/BUILD.LOG.armhf
> ...
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt30-trusty/BUILD.LOG.armhf


 -Kamal