From: Christophe LEROY <christophe.leroy@c-s.fr>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Christian Kujau <lists@nerdbynature.de>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'
Date: Thu, 12 Jan 2017 15:42:34 +0100 [thread overview]
Message-ID: <7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr> (raw)
In-Reply-To: <1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>
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 global variable
>>> __stack_chk_guard as canary value, but a value stored at -0x7008(r2).
>>> This is not compatible with the current implementation of the kernel
>>> with uses r2 as a pointeur to current task struct.
>>> So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC
>>> with modern versions of GCC.
>>
>> I still wonder what changed. Nothing relevant has changed for ten years
>> or whatever as far as I see; unless it is just the
>> -fstack-protector-strong
>> that makes it fail now. Curious.
>>
>
> Yes, looks like it was changed from global to TLS in 2005 on powerpc.
> Indeed when I implemented STACKPROTECTOR in Kernel on ppc I
> copied/pasted it from ARM which is (still?) using the global
> __stack_chk_guard, and at first it worked quite well on my powerpc.
>
> x86 has the following option on GCC. Couldn't we have it on powerpc too ?
>
> -mstack-protector-guard=guard
> Generate stack protection code using canary at
> guard. Supported locations are ‘ global ’ for global canary or ‘ tls
> ’ for per-thread canary in the TLS block (the default). This option
> has effect only when ‘-fstack-protector’ or ‘-fstack-protector-all’
> is specified.
>
Finally, it looks like it is not so easy.
I have three instances of GCC:
* 4.4.4, home built
* 4.6.3, from https://www.kernel.org/pub/tools/crosstool/
* 4.8.3, home built
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 of the 3 GCC versions.
Christophe
Using built-in specs.
Target: ppc-linux
Configured with: /root/cldk/gcc-4.4.4/configure --target=ppc-linux
--with-headers=yes --with-cpu=860 --prefix=/opt/cldk
--bindir=/opt/cldk/bin --sbindir=/opt/cldk/sbin
--libexecdir=/opt/cldk/libexec --datadir=/opt/cldk/share
--sysconfdir=/opt/cldk/etc --libdir=/opt/cldk/lib
--includedir=/opt/cldk/usr/include --oldincludedir=/opt/cldk/usr/include
--infodir=/opt/cldk/share/info --mandir=/opt/cldk/share/man
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.4 (GCC)
0000007c <name_to_dev_t>:
7c: 7c 08 02 a6 mflr r0
80: 94 21 ff a0 stwu r1,-96(r1)
84: 3c 80 00 00 lis r4,0
86: R_PPC_ADDR16_HA .rodata.str1.4+0x1bc
88: 93 c1 00 58 stw r30,88(r1)
8c: 93 e1 00 5c stw r31,92(r1)
90: 90 01 00 64 stw r0,100(r1)
94: 93 81 00 50 stw r28,80(r1)
98: 93 a1 00 54 stw r29,84(r1)
9c: 38 84 01 bc addi r4,r4,444
9e: R_PPC_ADDR16_LO .rodata.str1.4+0x1bc
a0: 38 a0 00 09 li r5,9
a4: 80 02 8f f8 lwz r0,-28680(r2)
a8: 90 01 00 4c stw r0,76(r1)
[...]
fc: 80 01 00 4c lwz r0,76(r1)
100: 81 22 8f f8 lwz r9,-28680(r2)
104: 7c 00 4a 79 xor. r0,r0,r9
108: 39 20 00 00 li r9,0
10c: 7f a3 eb 78 mr r3,r29
110: 40 82 03 88 bne- 498 <name_to_dev_t+0x41c>
[...]
498: 48 00 00 01 bl 498 <name_to_dev_t+0x41c>
498: R_PPC_REL24 __stack_chk_fail
Using built-in specs.
COLLECT_GCC=powerpc64-linux-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.6.3-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/4.6.3/lto-wrapper
Target: powerpc64-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=powerpc64-linux --host=i686-linux-gnu --build=i686-linux-gnu
--enable-targets=all
--prefix=/opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/
--enable-languages=c --with-newlib --without-headers
--enable-sjlj-exceptions --with-system-libunwind --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --enable-checking=release
--with-mpfr=/home/tony/buildall/src/sys-i686
--with-gmp=/home/tony/buildall/src/sys-i686 --disable-bootstrap
--disable-libquadmath
Thread model: single
gcc version 4.6.3 (GCC)
000000c0 <name_to_dev_t>:
c0: 94 21 ff a0 stwu r1,-96(r1)
c4: 7c 08 02 a6 mflr r0
c8: 3c 80 00 00 lis r4,0
ca: R_PPC_ADDR16_HA .rodata.str1.4+0x50
cc: 38 a0 00 09 li r5,9
d0: 38 84 00 50 addi r4,r4,80
d2: R_PPC_ADDR16_LO .rodata.str1.4+0x50
d4: bf 81 00 50 stmw r28,80(r1)
d8: 3f e0 00 00 lis r31,0
da: R_PPC_ADDR16_HA __stack_chk_guard
dc: 7c 7e 1b 78 mr r30,r3
e0: 90 01 00 64 stw r0,100(r1)
e4: 3b ff 00 00 addi r31,r31,0
e6: R_PPC_ADDR16_LO __stack_chk_guard
e8: 80 1f 00 00 lwz r0,0(r31)
ec: 90 01 00 4c stw r0,76(r1)
[...]
13c: 81 21 00 4c lwz r9,76(r1)
140: 80 1f 00 00 lwz r0,0(r31)
144: 7d 29 02 79 xor. r9,r9,r0
148: 38 00 00 00 li r0,0
14c: 7f 83 e3 78 mr r3,r28
150: 40 82 03 68 bne- 4b8 <name_to_dev_t+0x3f8>
[...]
4b8: 48 00 00 01 bl 4b8 <name_to_dev_t+0x3f8>
4b8: R_PPC_REL24 __stack_chk_fail
Using built-in specs.
COLLECT_GCC=ppc-linux-gcc
COLLECT_LTO_WRAPPER=/opt/cldk/libexec/gcc/ppc-linux/4.8.3/lto-wrapper
Target: ppc-linux
Configured with: /root/cldk/gcc-4.8.3/configure --target=ppc-linux
--with-headers=yes --with-cpu=860 --prefix=/opt/cldk
--bindir=/opt/cldk/bin --sbindir=/opt/cldk/sbin
--libexecdir=/opt/cldk/libexec --datadir=/opt/cldk/share
--sysconfdir=/opt/cldk/etc --libdir=/opt/cldk/lib
--includedir=/opt/cldk/usr/include --oldincludedir=/opt/cldk/usr/include
--infodir=/opt/cldk/share/info --mandir=/opt/cldk/share/man
--enable-languages=c,c++
Thread model: posix
gcc version 4.8.3 (GCC)
000000b0 <name_to_dev_t>:
b0: 7c 08 02 a6 mflr r0
b4: 94 21 ff a0 stwu r1,-96(r1)
b8: 3c 80 00 00 lis r4,0
ba: R_PPC_ADDR16_HA .rodata.str1.4+0x50
bc: bf a1 00 54 stmw r29,84(r1)
c0: 90 01 00 64 stw r0,100(r1)
c4: 38 84 00 00 addi r4,r4,0
c6: R_PPC_ADDR16_LO .rodata.str1.4+0x50
c8: 38 a0 00 09 li r5,9
cc: 7c 7f 1b 78 mr r31,r3
d0: 81 22 8f f8 lwz r9,-28680(r2)
d4: 91 21 00 4c stw r9,76(r1)
[...]
124: 81 41 00 4c lwz r10,76(r1)
128: 81 22 8f f8 lwz r9,-28680(r2)
12c: 7d 4a 4a 79 xor. r10,r10,r9
130: 39 20 00 00 li r9,0
134: 40 82 03 70 bne 4a4 <name_to_dev_t+0x3f4>
[...]
4a4: 48 00 00 01 bl 4a4 <name_to_dev_t+0x3f4>
4a4: R_PPC_REL24 __stack_chk_fail
next prev parent reply other threads:[~2017-01-12 14:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-03 15:25 bootx_init.c:88: undefined reference to `__stack_chk_fail_local' Christian Kujau
2017-01-03 19:20 ` Christian Kujau
2017-01-03 22:50 ` Benjamin Herrenschmidt
2017-01-03 22:57 ` Christian Kujau
2017-01-04 8:23 ` Christophe LEROY
2017-01-04 8:40 ` Segher Boessenkool
2017-01-04 7:32 ` Christophe LEROY
2017-01-04 15:22 ` Christian Kujau
2017-01-04 18:33 ` Christian Kujau
2017-01-10 2:11 ` Christian Kujau
2017-01-10 4:32 ` Benjamin Herrenschmidt
2017-01-10 6:12 ` Christophe LEROY
2017-01-10 18:46 ` Christian Kujau
2017-01-10 6:26 ` Christophe LEROY
2017-01-11 22:54 ` Segher Boessenkool
2017-01-12 7:52 ` Christophe LEROY
2017-01-12 14:42 ` Christophe LEROY [this message]
2017-01-12 15:20 ` Benjamin Herrenschmidt
2017-01-12 18:07 ` Segher Boessenkool
2017-01-13 12:15 ` Christophe LEROY
2017-01-13 12:23 ` David Laight
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=7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=benh@au1.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lists@nerdbynature.de \
--cc=segher@kernel.crashing.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.