From: Christophe LEROY
> Sent: 13 January 2017 12:15
...
> > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally
> > be true for glibc >= 2.4), and that is all. Mystery solved. Thanks!
> >
>
> Is there a way to know during compilation how the compiler will behave,
> in
Le 12/01/2017 à 19:07, Segher Boessenkool a écrit :
On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote:
On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:
The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use
-28680(r2)
Is it dependent on the way GCC is
On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote:
> On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:
> > The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use
> > -28680(r2)
> >
> > Is it dependent on the way GCC is built ? Then do we have a way to
> >
On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:
> The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use
> -28680(r2)
>
> Is it dependent on the way GCC is built ? Then do we have a way to
> know,
> when we compile, which method GCC will use ?
>
> See details below for each
Le 12/01/2017 à 08:52, Christophe LEROY a écrit :
Le 11/01/2017 à 23:54, Segher Boessenkool a écrit :
On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote:
Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?
Indeed, the latest versions of GCC don't use anymore the
Le 11/01/2017 à 23:54, Segher Boessenkool a écrit :
On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote:
Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?
Indeed, the latest versions of GCC don't use anymore the global variable
__stack_chk_guard as canary value,
On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote:
> >Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?
>
> Indeed, the latest versions of GCC don't use anymore the global variable
> __stack_chk_guard as canary value, but a value stored at -0x7008(r2).
> This is
On Mon, 9 Jan 2017, Benjamin Herrenschmidt wrote:
> On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote:
> > So, with -fno-stack-protector my GCC 4.9.2 compiles with
> > CC_STACKPROTECTOR_STRONG=y but panics during boot:
>
> How can it make any sense to have -fno-stack-protector and
>
Le 10/01/2017 à 03:11, Christian Kujau a écrit :
On Wed, 4 Jan 2017, Christian Kujau wrote:
So, would the following be sufficient? It compiles, but I haven't had a
chance to boot yet.
So, with -fno-stack-protector my GCC 4.9.2 compiles with
CC_STACKPROTECTOR_STRONG=y but panics during
Le 10/01/2017 à 05:32, Benjamin Herrenschmidt a écrit :
On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote:
So, with -fno-stack-protector my GCC 4.9.2 compiles with
CC_STACKPROTECTOR_STRONG=y but panics during boot:
How can it make any sense to have -fno-stack-protector and
On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote:
> So, with -fno-stack-protector my GCC 4.9.2 compiles with
> CC_STACKPROTECTOR_STRONG=y but panics during boot:
How can it make any sense to have -fno-stack-protector and
CC_STACKPROTECTOR_STRONG=y at the same time ?
Ben.
On Wed, 4 Jan 2017, Christian Kujau wrote:
> So, would the following be sufficient? It compiles, but I haven't had a
> chance to boot yet.
>
So, with -fno-stack-protector my GCC 4.9.2 compiles with
CC_STACKPROTECTOR_STRONG=y but panics during boot:
Kernel panic - not syncing:
On Wed, 4 Jan 2017, Christophe LEROY wrote:
> Using GCC 5.4.0, I don't have that issue. bootx_init.o only contains reference
> to __stack_chk_fail
FWIW, building with a GCC 5.2 crosscompiler succeeds (with
CONFIG_CC_STACKPROTECTOR_STRONG=y), but I don't know if it will boot
though, see my other
On Wed, 4 Jan 2017, Christophe LEROY wrote:
> Looking a bit over internet, some people have reported having encountered that
> issue due to old object files not properly cleaned.
> Have you tried a 'make clean' or 'distclean' ?
I'm compiling with O=$DIR and I've deleted the entire $DIR before
On Wed, Jan 04, 2017 at 09:23:47AM +0100, Christophe LEROY wrote:
> >The way gcc implements the stack protector has some serious
> >incompatibilities with the way the Linux kernel uses r13, I wouldn't
> >even try until we sort that out...
>
> Yes indeed, it looks like recent versions of GCC don't
Le 03/01/2017 à 23:50, Benjamin Herrenschmidt a écrit :
On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:
Hi,
when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
linker fails with:
The way gcc implements the stack protector has some serious
incompatibilities with
Le 03/01/2017 à 16:25, Christian Kujau a écrit :
Hi,
when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
linker fails with:
+ ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T
./arch/powerpc/kernel/vmlinux.lds
On Wed, 4 Jan 2017, Benjamin Herrenschmidt wrote:
> On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:
> > Hi,
> >
> > when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
> > linker fails with:
>
> The way gcc implements the stack protector has some serious
>
On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:
> Hi,
>
> when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
> linker fails with:
The way gcc implements the stack protector has some serious
incompatibilities with the way the Linux kernel uses r13, I wouldn't
even try
On Tue, 3 Jan 2017, Christian Kujau wrote:
> when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
> linker fails with:
FWIW, compiling with CONFIG_CC_STACKPROTECTOR_REGULAR=y instead works
just fine.
C.
>
>
> + ld -EB -m elf32ppc -Bstatic
20 matches
Mail list logo
