* bootx_init.c:88: undefined reference to `__stack_chk_fail_local' @ 2017-01-03 15:25 Christian Kujau 2017-01-03 19:20 ` Christian Kujau ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Christian Kujau @ 2017-01-03 15:25 UTC (permalink / raw) To: Christophe Leroy; +Cc: Michael Ellerman, linuxppc-dev 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 arch/powerpc/kernel/head_32.o arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o arch/powerpc/kernel/prom_init.o init/built-in.o --start-group usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o --end-group arch/powerpc/platforms/built-in.o: In function `bootx_printf': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined reference to `__stack_chk_fail_local' arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined reference to `__stack_chk_fail_local' arch/powerpc/platforms/built-in.o: In function `bootx_scan_dt_build_struct': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined reference to `__stack_chk_fail_local' arch/powerpc/platforms/built-in.o: In function `bootx_init': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined reference to `__stack_chk_fail_local' /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' isn't defined /usr/bin/ld.bfd.real: final link failed: Bad value ================================ $ ld --version | head -1 GNU ld (GNU Binutils for Debian) 2.25 $ gcc --version | head -1 gcc-4.9.real (Debian 4.9.2-10) 4.9.2 I'm regularly compiling userspace programs with -fstack-protector w/o problems. I suspect it's either 6533b7c16ee5712041b4e324100550e02a9a5dda ("powerpc: Initial stack protector (-fstack-protector) support") or 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the stack protector canary value per task") or both but I haven't started the bisection yet. Any other ideas? Thanks, Christian. -- BOFH excuse #220: Someone thought The Big Red Button was a light switch. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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-04 7:32 ` Christophe LEROY 2 siblings, 0 replies; 21+ messages in thread From: Christian Kujau @ 2017-01-03 19:20 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev, Michael Ellerman 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 --build-id -X -o .tmp_vmlinux1 -T > ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o > arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o > arch/powerpc/kernel/prom_init.o init/built-in.o --start-group > usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o > arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o > kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o > ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o > lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o > firmware/built-in.o net/built-in.o virt/built-in.o --end-group > arch/powerpc/platforms/built-in.o: In function `bootx_printf': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function > `bootx_scan_dt_build_struct': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function `bootx_init': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined reference to `__stack_chk_fail_local' > /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' isn't defined > /usr/bin/ld.bfd.real: final link failed: Bad value > ================================ > > > $ ld --version | head -1 > GNU ld (GNU Binutils for Debian) 2.25 > > $ gcc --version | head -1 > gcc-4.9.real (Debian 4.9.2-10) 4.9.2 > > > I'm regularly compiling userspace programs with -fstack-protector w/o > problems. I suspect it's either 6533b7c16ee5712041b4e324100550e02a9a5dda > ("powerpc: Initial stack protector (-fstack-protector) support") or > 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the stack > protector canary value per task") or both but I haven't started the > bisection yet. > > Any other ideas? > > Thanks, > Christian. > -- > BOFH excuse #220: > > Someone thought The Big Red Button was a light switch. > -- BOFH excuse #413: Cow-tippers tipped a cow onto the server. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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 7:32 ` Christophe LEROY 2 siblings, 2 replies; 21+ messages in thread From: Benjamin Herrenschmidt @ 2017-01-03 22:50 UTC (permalink / raw) To: Christian Kujau, Christophe Leroy; +Cc: linuxppc-dev 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 until we sort that out... Cheers, Ben. > > ================================ > + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T > ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o > arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o > arch/powerpc/kernel/prom_init.o init/built-in.o --start-group > usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built- > in.o > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o > arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o > kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o > ipc/built-in.o security/built-in.o crypto/built-in.o block/built- > in.o > lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o > firmware/built-in.o net/built-in.o virt/built-in.o --end-group > arch/powerpc/platforms/built-in.o: In function `bootx_printf': > /usr/local/src/linux- > git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined > reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function > `bootx_add_display_props': > /usr/local/src/linux- > git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined > reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function > `bootx_scan_dt_build_struct': > /usr/local/src/linux- > git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined > reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function `bootx_init': > /usr/local/src/linux- > git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined > reference to `__stack_chk_fail_local' > /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol > `__stack_chk_fail_local' isn't defined > /usr/bin/ld.bfd.real: final link failed: Bad value > ================================ > > > $ ld --version | head -1 > GNU ld (GNU Binutils for Debian) 2.25 > > $ gcc --version | head -1 > gcc-4.9.real (Debian 4.9.2-10) 4.9.2 > > > I'm regularly compiling userspace programs with -fstack-protector > w/o > problems. I suspect it's either > 6533b7c16ee5712041b4e324100550e02a9a5dda > ("powerpc: Initial stack protector (-fstack-protector) support") or > 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the > stack > protector canary value per task") or both but I haven't started the > bisection yet. > > Any other ideas? > > Thanks, > Christian. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-03 22:50 ` Benjamin Herrenschmidt @ 2017-01-03 22:57 ` Christian Kujau 2017-01-04 8:23 ` Christophe LEROY 1 sibling, 0 replies; 21+ messages in thread From: Christian Kujau @ 2017-01-03 22:57 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Christophe Leroy, linuxppc-dev, Michael Ellerman 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 > incompatibilities with the way the Linux kernel uses r13, I wouldn't > even try until we sort that out... Yeah, I noticed. While _compilation_ succeeded with CONFIG_CC_STACKPROTECTOR_REGULAR=y, the kernel panicked during boot with: Kernel panic - not syning: stack-protector: Kernel stack is corrupted in: c0103894 CPU: 0 PID: 586 Comm: systemd Tainted: G W 4.10.0-rc2 #3 Call Trace: [ee949ca0] [c067d6cc] panic+0x114/0x268 (unreliable) [ee949d00] [c002be80] print_tainted+0x0/0xcc [ee949d10] [c0103894] path_openat+0x1014/0x1050 [ee949df0] [c01048dc] do_filp_open+0xac/0xfc [ee949ea0] [c00f994c] do_open_execat+0x64/0x1bc [ee949ee0] [c00fb0f8] do_execveat_common+0x24c/0x774 [ee949f30] [c00fb650] do_execve+0x30/0x40 [ee949f40] [c0010db0] ret_from_syscall+0x0/0x38 --- interrupt: c01 at 0x20403618 LR = 0x204037ac (written down manually, hopefully w/o typos). I'll disable the stack protector on this powerpc (G4) machine for now. Thanks, Christian. > > Cheers, > Ben. > > > > ================================ > > + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T > > ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o > > arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o > > arch/powerpc/kernel/prom_init.o init/built-in.o --start-group > > usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built- > > in.o > > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o > > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o > > arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o > > kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o > > ipc/built-in.o security/built-in.o crypto/built-in.o block/built- > > in.o > > lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o > > firmware/built-in.o net/built-in.o virt/built-in.o --end-group > > arch/powerpc/platforms/built-in.o: In function `bootx_printf': > > /usr/local/src/linux- > > git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined > > reference to `__stack_chk_fail_local' > > arch/powerpc/platforms/built-in.o: In function > > `bootx_add_display_props': > > /usr/local/src/linux- > > git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined > > reference to `__stack_chk_fail_local' > > arch/powerpc/platforms/built-in.o: In function > > `bootx_scan_dt_build_struct': > > /usr/local/src/linux- > > git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined > > reference to `__stack_chk_fail_local' > > arch/powerpc/platforms/built-in.o: In function `bootx_init': > > /usr/local/src/linux- > > git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined > > reference to `__stack_chk_fail_local' > > /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol > > `__stack_chk_fail_local' isn't defined > > /usr/bin/ld.bfd.real: final link failed: Bad value > > ================================ > > > > > > $ ld --version | head -1 > > GNU ld (GNU Binutils for Debian) 2.25 > > > > $ gcc --version | head -1 > > gcc-4.9.real (Debian 4.9.2-10) 4.9.2 > > > > > > I'm regularly compiling userspace programs with -fstack-protector > > w/o > > problems. I suspect it's either > > 6533b7c16ee5712041b4e324100550e02a9a5dda > > ("powerpc: Initial stack protector (-fstack-protector) support") or > > 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the > > stack > > protector canary value per task") or both but I haven't started the > > bisection yet. > > > > Any other ideas? > > > > Thanks, > > Christian. > > -- BOFH excuse #111: The salesman drove over the CPU board. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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 1 sibling, 1 reply; 21+ messages in thread From: Christophe LEROY @ 2017-01-04 8:23 UTC (permalink / raw) To: benh, Christian Kujau; +Cc: linuxppc-dev 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 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 use anymore the global __stack_chk_guard variable but a hard coded offset relative to r2 or r13: On 32 bits, it uses -7008(r2) On 64 bits, it uses -7010(r13) On 32 bits, r2 points to current struct, which contains the stack_canary value for the task. I have tried to alter get_current() in order to define it as an offset to r2 so that current->stack_canary is at -7008(r2), but I end up with circular cross references in header files and still have task_struct undefined when get_current() needs it to calculate offset of stack_canary within the structure. When CONFIG_CC_STACKPROTECTOR is active, would it be feasible to get the pointer to current from the stack using the thread_info instead of using r2 reg ? That way we could keep r2 to point to current->stack_canary + 0x7008 Christophe > > Cheers, > Ben. >> >> ================================ >> + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T >> ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o >> arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o >> arch/powerpc/kernel/prom_init.o init/built-in.o --start-group >> usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built- >> in.o >> arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o >> arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o >> arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o >> kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o >> ipc/built-in.o security/built-in.o crypto/built-in.o block/built- >> in.o >> lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o >> firmware/built-in.o net/built-in.o virt/built-in.o --end-group >> arch/powerpc/platforms/built-in.o: In function `bootx_printf': >> /usr/local/src/linux- >> git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined >> reference to `__stack_chk_fail_local' >> arch/powerpc/platforms/built-in.o: In function >> `bootx_add_display_props': >> /usr/local/src/linux- >> git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined >> reference to `__stack_chk_fail_local' >> arch/powerpc/platforms/built-in.o: In function >> `bootx_scan_dt_build_struct': >> /usr/local/src/linux- >> git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined >> reference to `__stack_chk_fail_local' >> arch/powerpc/platforms/built-in.o: In function `bootx_init': >> /usr/local/src/linux- >> git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined >> reference to `__stack_chk_fail_local' >> /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol >> `__stack_chk_fail_local' isn't defined >> /usr/bin/ld.bfd.real: final link failed: Bad value >> ================================ >> >> >> $ ld --version | head -1 >> GNU ld (GNU Binutils for Debian) 2.25 >> >> $ gcc --version | head -1 >> gcc-4.9.real (Debian 4.9.2-10) 4.9.2 >> >> >> I'm regularly compiling userspace programs with -fstack-protector >> w/o >> problems. I suspect it's either >> 6533b7c16ee5712041b4e324100550e02a9a5dda >> ("powerpc: Initial stack protector (-fstack-protector) support") or >> 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the >> stack >> protector canary value per task") or both but I haven't started the >> bisection yet. >> >> Any other ideas? >> >> Thanks, >> Christian. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-04 8:23 ` Christophe LEROY @ 2017-01-04 8:40 ` Segher Boessenkool 0 siblings, 0 replies; 21+ messages in thread From: Segher Boessenkool @ 2017-01-04 8:40 UTC (permalink / raw) To: Christophe LEROY; +Cc: benh, Christian Kujau, linuxppc-dev 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 use anymore the > global __stack_chk_guard variable but a hard coded offset relative to r2 > or r13: > > On 32 bits, it uses -7008(r2) > On 64 bits, it uses -7010(r13) This is https://gcc.gnu.org/PR78875 . It should have been this way since forever; if it really wasn't, it is unclear why not. Either way, we (i.e. GCC) will add some compiler option to make this work for the kernel. It will be part of 7 and we'll probably backport it to 6.4 and 5.5 . For bootx_init.c, this probably should be compiled with -fno-stack-protector just like all the other boot time stuff. Segher ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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-04 7:32 ` Christophe LEROY 2017-01-04 15:22 ` Christian Kujau 2017-01-04 18:33 ` Christian Kujau 2 siblings, 2 replies; 21+ messages in thread From: Christophe LEROY @ 2017-01-04 7:32 UTC (permalink / raw) To: Christian Kujau; +Cc: Michael Ellerman, linuxppc-dev 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 arch/powerpc/kernel/head_32.o > arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o > arch/powerpc/kernel/prom_init.o init/built-in.o --start-group > usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o > arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o > kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o > ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o > lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o > firmware/built-in.o net/built-in.o virt/built-in.o --end-group > arch/powerpc/platforms/built-in.o: In function `bootx_printf': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function > `bootx_scan_dt_build_struct': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined reference to `__stack_chk_fail_local' > arch/powerpc/platforms/built-in.o: In function `bootx_init': > /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined reference to `__stack_chk_fail_local' > /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' isn't defined > /usr/bin/ld.bfd.real: final link failed: Bad value > ================================ > > > $ ld --version | head -1 > GNU ld (GNU Binutils for Debian) 2.25 > > $ gcc --version | head -1 > gcc-4.9.real (Debian 4.9.2-10) 4.9.2 > > > I'm regularly compiling userspace programs with -fstack-protector w/o > problems. I suspect it's either 6533b7c16ee5712041b4e324100550e02a9a5dda > ("powerpc: Initial stack protector (-fstack-protector) support") or > 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the stack > protector canary value per task") or both but I haven't started the > bisection yet. > > Any other ideas? > > Thanks, > Christian. > Using GCC 5.4.0, I don't have that issue. bootx_init.o only contains reference to __stack_chk_fail 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' ? Christophe ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-04 7:32 ` Christophe LEROY @ 2017-01-04 15:22 ` Christian Kujau 2017-01-04 18:33 ` Christian Kujau 1 sibling, 0 replies; 21+ messages in thread From: Christian Kujau @ 2017-01-04 15:22 UTC (permalink / raw) To: Christophe LEROY; +Cc: Michael Ellerman, linuxppc-dev 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 compilation. So no, old object files is not the issue here. Christian. -- BOFH excuse #105: UPS interrupted the server's power ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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 1 sibling, 1 reply; 21+ messages in thread From: Christian Kujau @ 2017-01-04 18:33 UTC (permalink / raw) To: Christophe LEROY Cc: Michael Ellerman, linuxppc-dev, Segher Boessenkool, Benjamin Herrenschmidt 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 mail in this thread: https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/152623.html So, would the following be sufficient? It compiles, but I haven't had a chance to boot yet. diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile index 1eb7b45..c7dcab9 100644 --- a/arch/powerpc/platforms/powermac/Makefile +++ b/arch/powerpc/platforms/powermac/Makefile @@ -1,4 +1,4 @@ -CFLAGS_bootx_init.o += -fPIC +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code Thanks, Christian. -- BOFH excuse #156: Zombie processes haunting the computer ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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:26 ` Christophe LEROY 0 siblings, 2 replies; 21+ messages in thread From: Christian Kujau @ 2017-01-10 2:11 UTC (permalink / raw) To: Christophe LEROY; +Cc: Benjamin Herrenschmidt, linuxppc-dev 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: stack-protector: Kernel stack is corrupted in: c069278c CPU: 0 PIP: 591 Comm: systemd Tainted: G W 4.10.0-rc3-dirty Call Trace: [ee965bb0] [c0693f5c] panic+0x120/0x274 (unreliable) [ee965c10] [c002c568] print_tainted+0x0/0xcc [ee965c20] [c069278c] schedule_timeout+0x25c/0x280 [ee965c80] [c068cc30] io_schedule_timeout+0x90/0xf4 [ee965ca0] [c00ac870] wait_on_page_bit_killable+0x1Oc/0x170 [ee965cf0] [c00ad240] __lock_page_or_retry+0xd4/0x12c [ee965d10] [c00ad708] filemap_fault+0x470/0x5b0 [ee965d60] [c00d07c8] __do_fault+0x2c/0x90 [ee965e40] [c00d4104] handle_mm__fault+0x7c0/0x9cc [ee965e00] [c0015a6c] do_page_fault+0x2ec,0x5b4 [ee965e40] [c0011660] handle_page_fault+0xc/0x80 --- interrupt: 301 at do_page_fault+0x394/0x5b4 LR = do_page_fault+0x378,0x5b4 [ee965f00] [c0015c04] do_page_fault+0x484/0x5b4 (unreliable) [ee965f40] [c0011660] handle_page_fault+0xc/0x80 --- interrupt: 401 at 0x2074d000 LR = 0x207cff0 Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ? Thanks, Christian. > > diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile > index 1eb7b45..c7dcab9 100644 > --- a/arch/powerpc/platforms/powermac/Makefile > +++ b/arch/powerpc/platforms/powermac/Makefile > @@ -1,4 +1,4 @@ > -CFLAGS_bootx_init.o += -fPIC > +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace early boot code > > > Thanks, > Christian. > -- > BOFH excuse #156: > > Zombie processes haunting the computer > -- BOFH excuse #450: Terrorists crashed an airplane into the server room, have to remove /bin/laden. (rm -rf /bin/laden) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 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 1 sibling, 2 replies; 21+ messages in thread From: Benjamin Herrenschmidt @ 2017-01-10 4:32 UTC (permalink / raw) To: Christian Kujau, Christophe LEROY; +Cc: linuxppc-dev 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-10 4:32 ` Benjamin Herrenschmidt @ 2017-01-10 6:12 ` Christophe LEROY 2017-01-10 18:46 ` Christian Kujau 1 sibling, 0 replies; 21+ messages in thread From: Christophe LEROY @ 2017-01-10 6:12 UTC (permalink / raw) To: benh, Christian Kujau; +Cc: linuxppc-dev 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 > CC_STACKPROTECTOR_STRONG=y at the same time ? > As far as I understand, Christian means no stack protector on file bootx_init.o, see below Christophe diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile index 1eb7b45..c7dcab9 100644 --- a/arch/powerpc/platforms/powermac/Makefile +++ b/arch/powerpc/platforms/powermac/Makefile @@ -1,4 +1,4 @@ -CFLAGS_bootx_init.o += -fPIC +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-10 4:32 ` Benjamin Herrenschmidt 2017-01-10 6:12 ` Christophe LEROY @ 2017-01-10 18:46 ` Christian Kujau 1 sibling, 0 replies; 21+ messages in thread From: Christian Kujau @ 2017-01-10 18:46 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Christophe LEROY, linuxppc-dev 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 > CC_STACKPROTECTOR_STRONG=y at the same time ? I've set -fno-stack-protector only for bootx_init.c, as laid out in the diff I posted. This way the kernel at least compiled. Thanks, Christian. -- BOFH excuse #423: It's not RFC-822 compliant. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-10 2:11 ` Christian Kujau 2017-01-10 4:32 ` Benjamin Herrenschmidt @ 2017-01-10 6:26 ` Christophe LEROY 2017-01-11 22:54 ` Segher Boessenkool 1 sibling, 1 reply; 21+ messages in thread From: Christophe LEROY @ 2017-01-10 6:26 UTC (permalink / raw) To: Christian Kujau; +Cc: Benjamin Herrenschmidt, linuxppc-dev 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 boot: > > > > 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. Christophe > > Thanks, > Christian. > >> >> diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile >> index 1eb7b45..c7dcab9 100644 >> --- a/arch/powerpc/platforms/powermac/Makefile >> +++ b/arch/powerpc/platforms/powermac/Makefile >> @@ -1,4 +1,4 @@ >> -CFLAGS_bootx_init.o += -fPIC >> +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector >> >> ifdef CONFIG_FUNCTION_TRACER >> # Do not trace early boot code >> >> >> Thanks, >> Christian. >> -- >> BOFH excuse #156: >> >> Zombie processes haunting the computer >> > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-10 6:26 ` Christophe LEROY @ 2017-01-11 22:54 ` Segher Boessenkool 2017-01-12 7:52 ` Christophe LEROY 0 siblings, 1 reply; 21+ messages in thread From: Segher Boessenkool @ 2017-01-11 22:54 UTC (permalink / raw) To: Christophe LEROY; +Cc: Christian Kujau, Benjamin Herrenschmidt, linuxppc-dev 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. Segher ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-11 22:54 ` Segher Boessenkool @ 2017-01-12 7:52 ` Christophe LEROY 2017-01-12 14:42 ` Christophe LEROY 0 siblings, 1 reply; 21+ messages in thread From: Christophe LEROY @ 2017-01-12 7:52 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Christian Kujau, Benjamin Herrenschmidt, linuxppc-dev 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. Christophe ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-12 7:52 ` Christophe LEROY @ 2017-01-12 14:42 ` Christophe LEROY 2017-01-12 15:20 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 21+ messages in thread From: Christophe LEROY @ 2017-01-12 14:42 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Christian Kujau, Benjamin Herrenschmidt, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-12 14:42 ` Christophe LEROY @ 2017-01-12 15:20 ` Benjamin Herrenschmidt 2017-01-12 18:07 ` Segher Boessenkool 0 siblings, 1 reply; 21+ messages in thread From: Benjamin Herrenschmidt @ 2017-01-12 15:20 UTC (permalink / raw) To: Christophe LEROY, Segher Boessenkool; +Cc: Christian Kujau, linuxppc-dev 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 of the 3 GCC versions. I think it depends if you built it along with glibc (so it can produce userspace binaries) or not. Cheers, Ben. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-12 15:20 ` Benjamin Herrenschmidt @ 2017-01-12 18:07 ` Segher Boessenkool 2017-01-13 12:15 ` Christophe LEROY 0 siblings, 1 reply; 21+ messages in thread From: Segher Boessenkool @ 2017-01-12 18:07 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Christophe LEROY, Christian Kujau, linuxppc-dev 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 > > know, > > when we compile, which method GCC will use ? > > > > See details below for each of the 3 GCC versions. > > I think it depends if you built it along with glibc (so it can produce > userspace binaries) or not. Right. Tony's compilers are built using a (modified version of) buildall, and buildall goes out of its way to build without libc whatsoever, even if the configuration (powerpc64-linux, for example) expects one. 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! Segher ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-12 18:07 ` Segher Boessenkool @ 2017-01-13 12:15 ` Christophe LEROY 2017-01-13 12:23 ` David Laight 0 siblings, 1 reply; 21+ messages in thread From: Christophe LEROY @ 2017-01-13 12:15 UTC (permalink / raw) To: Segher Boessenkool, Benjamin Herrenschmidt; +Cc: Christian Kujau, linuxppc-dev 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 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. >> >> I think it depends if you built it along with glibc (so it can produce >> userspace binaries) or not. > > Right. Tony's compilers are built using a (modified version of) buildall, > and buildall goes out of its way to build without libc whatsoever, even > if the configuration (powerpc64-linux, for example) expects one. > > 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 order to select the correct method ? I have drafted a new approach in the kernel that uses -0x7008(r2) instead of the global __stack_chk_guard, but how can I select the proper approach during kernel compilation in line with the selected GCC ? Christophe ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: bootx_init.c:88: undefined reference to `__stack_chk_fail_local' 2017-01-13 12:15 ` Christophe LEROY @ 2017-01-13 12:23 ` David Laight 0 siblings, 0 replies; 21+ messages in thread From: David Laight @ 2017-01-13 12:23 UTC (permalink / raw) To: 'Christophe LEROY', Segher Boessenkool, Benjamin Herrenschmidt Cc: Christian Kujau, linuxppc-dev From: Christophe LEROY > Sent: 13 January 2017 12:15 ... > > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would norma= lly > > be true for glibc >=3D 2.4), and that is all. Mystery solved. Thanks! > > >=20 > Is there a way to know during compilation how the compiler will behave, > in order to select the correct method ? >=20 > I have drafted a new approach in the kernel that uses -0x7008(r2) > instead of the global __stack_chk_guard, but how can I select the proper > approach during kernel compilation in line with the selected GCC ? Worse, how can you ensure that loadable modules are compiled with the same option as the rest of the kernel. David ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-01-13 12:23 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.