[PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1.1: Type: text/plain, Size: 461 bytes --]

Hi Guys,

I think the subject and patch says it all. Please see the attached minor
fix which allows ppc32 (2.6.16) to build with a non-vanilla gcc.

This could also be fixed in BOOTCFLAGS but I felt this being the more
appropriate.

Regards,
John

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #1.2: ppc32-2.6.16-fix.patch --]
[-- Type: text/plain, Size: 850 bytes --]

Since ppc32 has been made to use arch/powerpc it has introduced a build-time
regression where userland CFLAGS are being leaked. This is especially obvious
when a user tries to "make zImage" with an SSP enabled gcc.

This patch restores sanity.

Signed-off-by: John Mylchreest <johnm@gentoo.org>


--- linux-2.6/arch/powerpc/boot/Makefile.orig	2006-04-01 23:36:39.000000000 +0100
+++ linux-2.6/arch/powerpc/boot/Makefile	2006-04-01 23:36:55.000000000 +0100
@@ -65,7 +65,7 @@ clean-files := $(zlib) $(zlibheader) $(z
 
 
 quiet_cmd_bootcc = BOOTCC  $@
-      cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
+      cmd_bootcc = $(CROSS32CC) -D__KERNEL__ -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
 
 quiet_cmd_bootas = BOOTAS  $@
       cmd_bootas = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Sat, Apr 01, John Mylchreest wrote:

> Since ppc32 has been made to use arch/powerpc it has introduced a build-time
> regression where userland CFLAGS are being leaked. This is especially obvious
> when a user tries to "make zImage" with an SSP enabled gcc.

What build error do you get?

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 6693 bytes --]

On Sun, Apr 02, 2006 at 10:58:50AM +0200, Olaf Hering <olh@suse.de> wrote:
>  On Sat, Apr 01, John Mylchreest wrote:
> 
> > Since ppc32 has been made to use arch/powerpc it has introduced a build-time
> > regression where userland CFLAGS are being leaked. This is especially obvious
> > when a user tries to "make zImage" with an SSP enabled gcc.
> 
> What build error do you get?

As requested :)

$ gcc -v
Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.4
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include/g++-v3
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --disable-nls --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo Hardened 3.4.4-r1, HTB-3.4.4-1.00,
ssp-3.4.4-1.0, pie-8.7.8)

  BOOTLD  arch/powerpc/boot/zImage.vmode
  arch/powerpc/boot/prom.o(.text+0x19c): In function `call_prom':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/prom.o(.text+0x3a8): In function `call_prom_ret':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/prom.o(.text+0x448): In function `write':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/prom.o(.text+0x4d8): In function `string_match':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/prom.o(.text+0x5ac): In function `claim':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/prom.o(.got2+0x4): undefined reference to `__guard'
  arch/powerpc/boot/stdio.o(.text+0x84): In function `strnlen':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/stdio.o(.text+0x130): In function `skip_atoi':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/stdio.o(.text+0x374): In function `number':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/stdio.o(.text+0x5b0): In function `vsprintf':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/stdio.o(.text+0xba8): In function `sprintf':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/stdio.o(.text+0xca4): more undefined references to
  `__stack_smash_handler' follow
  arch/powerpc/boot/stdio.o(.got2+0x0): undefined reference to `__guard'
  arch/powerpc/boot/main.o(.text+0x198): In function `gunzip':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/main.o(.text+0x318): In function `try_claim':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/main.o(.text+0x5b0): In function `start':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/main.o(.got2+0x20): undefined reference to `__guard'
  arch/powerpc/boot/infblock.o(.text+0xac): In function
  `zlib_inflate_blocks_reset':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infblock.o(.text+0x180): In function
  `zlib_inflate_blocks_new':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infblock.o(.text+0x428): In function
  `zlib_inflate_blocks':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infblock.o(.text+0xd00): In function
  `zlib_inflate_blocks_free':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infblock.o(.got2+0x0): undefined reference to
  `__guard'
  arch/powerpc/boot/infcodes.o(.text+0x68): In function
  `zlib_inflate_codes_new':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infcodes.o(.text+0x18c): In function
  `zlib_inflate_codes':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infcodes.o(.text+0x8ec): In function
  `zlib_inflate_codes_free':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infcodes.o(.got2+0x0): undefined reference to
  `__guard'
  arch/powerpc/boot/inffast.o(.text+0x1a4): In function
  `zlib_inflate_fast':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inffast.o(.got2+0xc): undefined reference to
  `__guard'
  arch/powerpc/boot/inflate.o(.text+0x1b8): In function `zlib_adler32':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inflate.o(.text+0x21c): In function
  `zlib_inflate_workspacesize':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inflate.o(.text+0x2e0): In function
  `zlib_inflateReset':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inflate.o(.text+0x38c): In function
  `zlib_inflateEnd':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inflate.o(.text+0x438): In function
  `zlib_inflateInit2_':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inflate.o(.text+0x570): more undefined references to
  `__stack_smash_handler' follow
  arch/powerpc/boot/inflate.o(.got2+0x0): undefined reference to
  `__guard'
  arch/powerpc/boot/inftrees.o(.text+0x248): In function `huft_build':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inftrees.o(.text+0x63c): In function
  `zlib_inflate_trees_bits':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inftrees.o(.text+0x784): In function
  `zlib_inflate_trees_dynamic':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inftrees.o(.text+0xa68): In function
  `zlib_inflate_trees_fixed':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/inftrees.o(.got2+0x0): undefined reference to
  `__guard'
  arch/powerpc/boot/infutil.o(.text+0x114): In function
  `zlib_inflate_flush':
  : undefined reference to `__stack_smash_handler'
  arch/powerpc/boot/infutil.o(.got2+0x0): undefined reference to
  `__guard'
  make[2]: *** [arch/powerpc/boot/zImage.vmode] Error 1
  make[1]: *** [zImage] Error 2
  make: *** [zImage] Error 2
  

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Sun, Apr 02, John Mylchreest wrote:

>   BOOTLD  arch/powerpc/boot/zImage.vmode
>   arch/powerpc/boot/prom.o(.text+0x19c): In function `call_prom':
>   : undefined reference to `__stack_smash_handler'

Any this strange "security feature" is disabled by defining __KERNEL__?

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Sun, Apr 02, 2006 at 12:28:15PM +0200, Olaf Hering <olh@suse.de> wrote:
>  On Sun, Apr 02, John Mylchreest wrote:
> 
> >   BOOTLD  arch/powerpc/boot/zImage.vmode
> >   arch/powerpc/boot/prom.o(.text+0x19c): In function `call_prom':
> >   : undefined reference to `__stack_smash_handler'
> 
> Any this strange "security feature" is disabled by defining __KERNEL__?

That correct, yes. SSP is actually used by quite a lot of vendors, and
shouldn't be used outside of userland. Typically speaking it isn't, but
in this case its being leaked.

I've also heard some strange reports with ppc32 and 2.6.16 not
decompressing properly all of the time which might be related. I've not
been able to recreate this, nor heard any feedback yet.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Sun, Apr 02, John Mylchreest wrote:

> On Sun, Apr 02, 2006 at 12:28:15PM +0200, Olaf Hering <olh@suse.de> wrote:
> >  On Sun, Apr 02, John Mylchreest wrote:
> > 
> > >   BOOTLD  arch/powerpc/boot/zImage.vmode
> > >   arch/powerpc/boot/prom.o(.text+0x19c): In function `call_prom':
> > >   : undefined reference to `__stack_smash_handler'
> > 
> > Any this strange "security feature" is disabled by defining __KERNEL__?
> 
> That correct, yes. SSP is actually used by quite a lot of vendors, and
> shouldn't be used outside of userland. Typically speaking it isn't, but
> in this case its being leaked.

Either way, file a bugreport upstream to remove the dep on __KERNEL__ in
the gcc patch.

A patch which adds -fno-dumb-feature to CFLAGS may be acceptable.

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

On Sun, Apr 02, 2006 at 01:10:02PM +0200, Olaf Hering <olh@suse.de> wrote:
>  On Sun, Apr 02, John Mylchreest wrote:
> 
> > On Sun, Apr 02, 2006 at 12:28:15PM +0200, Olaf Hering <olh@suse.de> wrote:
> > >  On Sun, Apr 02, John Mylchreest wrote:
> > > 
> > > >   BOOTLD  arch/powerpc/boot/zImage.vmode
> > > >   arch/powerpc/boot/prom.o(.text+0x19c): In function `call_prom':
> > > >   : undefined reference to `__stack_smash_handler'
> > > 
> > > Any this strange "security feature" is disabled by defining __KERNEL__?
> > 
> > That correct, yes. SSP is actually used by quite a lot of vendors, and
> > shouldn't be used outside of userland. Typically speaking it isn't, but
> > in this case its being leaked.
> 
> Either way, file a bugreport upstream to remove the dep on __KERNEL__ in
> the gcc patch.
> 
> A patch which adds -fno-dumb-feature to CFLAGS may be acceptable.

Going from that, I can push a patch for gcc upstream to remove the
__KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.

-fno-stack-protector would work for gcc4, but for gcc3 it could still be
patially enabled, and requires -fno-stack-protector-all. Mind If I ask
whats incorrect about defining __KERNEL__ for the bootcflags?

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Sun, Apr 02, John Mylchreest wrote:

> Going from that, I can push a patch for gcc upstream to remove the
> __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.

gcc4.1 has no obvious problems with --enable-ssp

> -fno-stack-protector would work for gcc4, but for gcc3 it could still be
> patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> whats incorrect about defining __KERNEL__ for the bootcflags?

arch/powerpc/boot is no kernel code, its supposed to be selfcontained.
Prepare a patch which uses the cc-option macro.

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Arjan van de Ven]

> Going from that, I can push a patch for gcc upstream to remove the
> __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.
> 
> -fno-stack-protector would work for gcc4, but for gcc3 it could still be

since this is a thing you have to turn on to get it, not off to not get
it, I think you're missing something big here ;)

> patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> whats incorrect about defining __KERNEL__ for the bootcflags?

it's silly and it's a non-standard gcc ... better get the gcc fixed to
at least have the upstream protocol of having to turn it on not off..

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Sun, Apr 02, 2006 at 03:15:38PM +0200, Arjan van de Ven <arjan@infradead.org> wrote:
> 
> > Going from that, I can push a patch for gcc upstream to remove the
> > __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> > between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.
> > 
> > -fno-stack-protector would work for gcc4, but for gcc3 it could still be
> 
> since this is a thing you have to turn on to get it, not off to not get
> it, I think you're missing something big here ;)
> 
> > patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> > whats incorrect about defining __KERNEL__ for the bootcflags?
> 
> it's silly and it's a non-standard gcc ... better get the gcc fixed to
> at least have the upstream protocol of having to turn it on not off..

It gets turned on elsewhere (gcc spec), but principle for me is that if its
enabled it still leaks and breaks this code. At the moment (following
from existing patches you put to this list) this mix will break until we
get stack-protector ported.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Sun, Apr 02, John Mylchreest wrote:

> It gets turned on elsewhere (gcc spec), but principle for me is that if its
> enabled it still leaks and breaks this code. At the moment (following
> from existing patches you put to this list) this mix will break until we
> get stack-protector ported.

There are so many ebuild files which turn off random gcc options without
fixing the real bug in the compiler. Just add one more to the
kernel.ebuild or whatever its called.

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Sun, Apr 02, 2006 at 04:01:29PM +0200, Olaf Hering <olh@suse.de> wrote:
>  On Sun, Apr 02, John Mylchreest wrote:
> 
> > It gets turned on elsewhere (gcc spec), but principle for me is that if its
> > enabled it still leaks and breaks this code. At the moment (following
> > from existing patches you put to this list) this mix will break until we
> > get stack-protector ported.
> 
> There are so many ebuild files which turn off random gcc options without
> fixing the real bug in the compiler. Just add one more to the
> kernel.ebuild or whatever its called.

That's just showing the ignorance to how kernel-sources are hendled from
within gentoo (but this isnt gentoo specific anyways. Its relative to
the gcc spec file were using). Once I get a little time this afternoon I
will look at a cleaner fix.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Arjan van de Ven]

On Sun, 2006-04-02 at 14:56 +0100, John Mylchreest wrote:
> On Sun, Apr 02, 2006 at 03:15:38PM +0200, Arjan van de Ven <arjan@infradead.org> wrote:
> > 
> > > Going from that, I can push a patch for gcc upstream to remove the
> > > __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> > > between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.
> > > 
> > > -fno-stack-protector would work for gcc4, but for gcc3 it could still be
> > 
> > since this is a thing you have to turn on to get it, not off to not get
> > it, I think you're missing something big here ;)
> > 
> > > patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> > > whats incorrect about defining __KERNEL__ for the bootcflags?
> > 
> > it's silly and it's a non-standard gcc ... better get the gcc fixed to
> > at least have the upstream protocol of having to turn it on not off..
> 
> It gets turned on elsewhere (gcc spec),

ehh???
so you change gcc to force a specific, non-standard option on, and
something breaks as a result... better get the gcc spec fixed I'd say 

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Sun, Apr 02, 2006 at 04:49:37PM +0200, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sun, 2006-04-02 at 14:56 +0100, John Mylchreest wrote:
> > On Sun, Apr 02, 2006 at 03:15:38PM +0200, Arjan van de Ven <arjan@infradead.org> wrote:
> > > 
> > > > Going from that, I can push a patch for gcc upstream to remove the
> > > > __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> > > > between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.
> > > > 
> > > > -fno-stack-protector would work for gcc4, but for gcc3 it could still be
> > > 
> > > since this is a thing you have to turn on to get it, not off to not get
> > > it, I think you're missing something big here ;)
> > > 
> > > > patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> > > > whats incorrect about defining __KERNEL__ for the bootcflags?
> > > 
> > > it's silly and it's a non-standard gcc ... better get the gcc fixed to
> > > at least have the upstream protocol of having to turn it on not off..
> > 
> > It gets turned on elsewhere (gcc spec),
> 
> ehh???
> so you change gcc to force a specific, non-standard option on, and
> something breaks as a result... better get the gcc spec fixed I'd say 

Yeah, something which I completely disregarded without thinking about
until this thread. Always helps not looking at this at 1am ;)
I always thought the arch/boot code should stay as part of the kernel
build. I'll re-address :)

Cheers for the input.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --]

On Sun, Apr 02, 2006 at 01:42:15PM +0200, Olaf Hering <olh@suse.de> wrote:
>  On Sun, Apr 02, John Mylchreest wrote:
> 
> > Going from that, I can push a patch for gcc upstream to remove the
> > __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> > between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.
> 
> gcc4.1 has no obvious problems with --enable-ssp
> 
> > -fno-stack-protector would work for gcc4, but for gcc3 it could still be
> > patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> > whats incorrect about defining __KERNEL__ for the bootcflags?
> 
> arch/powerpc/boot is no kernel code, its supposed to be selfcontained.
> Prepare a patch which uses the cc-option macro.

As requested, please see attached a small patch which rectifies this
with negating cflags. The cc-option macro won't always work, and as such
I have declared a new macro to honour $(CROSS32CC).

Thoughts welcome,
John

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #1.2: ppc32-2.6.16-sspcc.patch --]
[-- Type: text/plain, Size: 1104 bytes --]

--- a/arch/powerpc/boot/Makefile	2006-04-03 17:33:44.000000000 +0000
+++ b/arch/powerpc/boot/aMakefile	2006-04-04 08:51:13.000000000 +0000
@@ -21,9 +21,19 @@
 #	in the toplevel makefile.
 
 
+# cc-option-crosscc
+# We can't rely on the host compiler in this situation, so we define
+# a modified cc-option macro for this task.
+# Usage: cflags-y += $(call cc-option-crosscc, -march=winchip-c6, -march=i586)
+
+cc-option-crosscc = $(shell if $(CROSS32CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
+                     > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+
 HOSTCC		:= gcc
 BOOTCFLAGS	:= $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
-		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC
+		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+		   $(call cc-option-crosscc, -fno-stack-protector) \
+		   $(call cc-option-crosscc, -fno-stack-protector-all)
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc 
 OBJCOPYFLAGS    := contents,alloc,load,readonly,data
 OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Tue, Apr 04, John Mylchreest wrote:

> On Sun, Apr 02, 2006 at 01:42:15PM +0200, Olaf Hering <olh@suse.de> wrote:
> >  On Sun, Apr 02, John Mylchreest wrote:
> > 
> > > Going from that, I can push a patch for gcc upstream to remove the
> > > __KERNEL__ dep, but gcc4.1 ships with ssp by standard, and the semantics
> > > between the IBM patch for SSP applied to gcc-3 and ggc-4 have changed.
> > 
> > gcc4.1 has no obvious problems with --enable-ssp
> > 
> > > -fno-stack-protector would work for gcc4, but for gcc3 it could still be
> > > patially enabled, and requires -fno-stack-protector-all. Mind If I ask
> > > whats incorrect about defining __KERNEL__ for the bootcflags?
> > 
> > arch/powerpc/boot is no kernel code, its supposed to be selfcontained.
> > Prepare a patch which uses the cc-option macro.
> 
> As requested, please see attached a small patch which rectifies this
> with negating cflags. The cc-option macro won't always work, and as such
> I have declared a new macro to honour $(CROSS32CC).

I think this should go into the main makefile, HOSTCFLAGS or similar. If
you look around quickly in the gentoo bugzilla, all non-userland
packages (grub, xen, kernel etc.) require the -fno-feature.

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Tue, Apr 04, 2006 at 11:41:24AM +0200, Olaf Hering <olh@suse.de> wrote:
> I think this should go into the main makefile, HOSTCFLAGS or similar. If
> you look around quickly in the gentoo bugzilla, all non-userland
> packages (grub, xen, kernel etc.) require the -fno-feature.

I'm not completely sure I understand where you are coming from here?
I assume you mean adding -fno-stack-protector to the host userlands
CFLAGS variable (or similar) to make it a global change, but if so
you're missing my point.

Effectively, anyone who currently has -fstack-protector enabled in
userland (regardless of distribution, or otherwise) will fail to build
the tools required. I do realise that gcc should not call this stuff
with ssp enabled, but there are legitimate cases for this to happen.
Also, just to bare in mind that this does not occur anywhere else except
for the "self-contained" code in arch/powerpc/boot, and it only occurs
here because we have a different userland and kernel ABI.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[Olaf Hering]

 On Tue, Apr 04, John Mylchreest wrote:

> On Tue, Apr 04, 2006 at 11:41:24AM +0200, Olaf Hering <olh@suse.de> wrote:
> > I think this should go into the main makefile, HOSTCFLAGS or similar. If
> > you look around quickly in the gentoo bugzilla, all non-userland
> > packages (grub, xen, kernel etc.) require the -fno-feature.
> 
> I'm not completely sure I understand where you are coming from here?
> I assume you mean adding -fno-stack-protector to the host userlands
> CFLAGS variable (or similar) to make it a global change, but if so
> you're missing my point.

I mean the whole kernel should be compiled with it, if you put it into
global cflags, the boot parts will pick it up from there.

Re: [PATCH 1/1] POWERPC: Fix ppc32 compile with gcc+SSP in 2.6.16

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Tue, Apr 04, 2006 at 12:58:26PM +0200, Olaf Hering <olh@suse.de> wrote:
>  On Tue, Apr 04, John Mylchreest wrote:
> 
> > On Tue, Apr 04, 2006 at 11:41:24AM +0200, Olaf Hering <olh@suse.de> wrote:
> > > I think this should go into the main makefile, HOSTCFLAGS or similar. If
> > > you look around quickly in the gentoo bugzilla, all non-userland
> > > packages (grub, xen, kernel etc.) require the -fno-feature.
> > 
> > I'm not completely sure I understand where you are coming from here?
> > I assume you mean adding -fno-stack-protector to the host userlands
> > CFLAGS variable (or similar) to make it a global change, but if so
> > you're missing my point.
> 
> I mean the whole kernel should be compiled with it, if you put it into
> global cflags, the boot parts will pick it up from there.

Sorry, for the belated reply. I thought that might be what you refered to,
however I think this is going to cause additional problems. The powerpc
code which is effected uses the CROSS32CC which may, or may not be the
same compiler as used by the host cc. This means that it could also have
different capabilities, and the worst scenario in this specific
situation would be where the hostcc didn't support ssp, but the
cross32cc did, and had it enforced.

I don't think this is the right approach, and keeping it isolated to the
boot code makes more sense to me.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]