After you have compiled freebsd-lib with gcc-4.9, all commands return Abort trap: 6 (core dumped). This bug until it is fixed, please do not unmask gcc-4.9.0 on Gentoo/FreeBSD. Reproducible: Always Steps to Reproduce: 1. Install gcc-4.9.0 and set 4.9.0 using gcc-config 2. emerge freebsd-lib 3. ls Actual Results: # ls Abort trap: 6 (core dumped)
# ebuild freebsd-lib-9.1-r11.ebuild clean install # LD_LIBRARY_PATH=/var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib/ ./hello Abort trap: 6 (core dumped) # gdb hello hello.core GNU gdb (Gentoo 7.6.2 p1) 7.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-gentoo-freebsd9.1". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /root/hello...done. [New process 100142] Core was generated by `hello'. Program terminated with signal 6, Aborted. #0 0x000000080092314c in kill () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 (gdb) bt #0 0x000000080092314c in kill () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 #1 0x00000008008c43f8 in ?? () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 #2 0x00000008008c4420 in __stack_chk_fail () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 #3 0x000000080085192e in ?? () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 #4 0x00000008009251b6 in ?? () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 #5 0x00007fffffffd208 in ?? () #6 0x00007fffffffd180 in ?? () #7 0x0000000800619080 in ?? () #8 0x000000080084df26 in ?? () from /var/tmp/portage/sys-freebsd/freebsd-lib-9.1-r11/image/lib//libc.so.7 #9 0x00007fffffffd180 in ?? () #10 0x0000000800604a77 in ?? () from /libexec/ld-elf.so.1 #11 0x0000000800608fc7 in ?? () from /libexec/ld-elf.so.1 #12 0x0000000800602475 in ?? () from /libexec/ld-elf.so.1 #13 0x0000000000000000 in ?? () (gdb)
Created attachment 379018 [details, diff] patch for freebsd-mk-defs-9.1
Created attachment 379020 [details, diff] patch for freebsd-lib-9.1
When you do not specify anything, -fstack-protector-strong is enabled in gcc-4.9. It's the cause of this problem. These patches add -fno-stack-protector, change the operation as before. Welcome a better way and patches. Thanks in advance. FYI, gcc-4.9.0 -dumpspecs, ssp_default part. ) *ssp_default: %{fno-stack-protector|fstack-protector| fstack-protector-strong|fstack-protector-all| ffreestanding|nostdlib:;:-fstack-protector-strong}
I don't think you need to disable it altogether. Looking at the context it looks like it handles -fstack-protector just fine. And -fstack-protector-strong should work in general on freebsd. They even backported it to 4.8 IIRC.
(In reply to Ryan Hill from comment #5) Thanks for reply. > I don't think you need to disable it altogether. Looking at the context it > looks like it handles -fstack-protector just fine. About attachment 379018 [details, diff], When MK_SSP=no is included in Makefile, -fno-stack-protector is added. Also, if the user specifies WITHOUT_SSP=YES. Otherwise, SSP is enabled basically. -fstack-protector is enabled. .if ${MK_SSP} != "no" SSP_CFLAGS?= -fstack-protector .else SSP_CFLAGS= -fno-stack-protector .endif # SSP CFLAGS+= ${SSP_CFLAGS} About attachment 379020 [details, diff], If the file name is stack_protector.c, add -fno-stack-protector to SSP_CFLAGS. +SSP_CFLAGS:= ${.IMPSRC:N*/stack_protector.c:C/^.+$/${SSP_CFLAGS}/:C/^$/-fno-stack-protector/} In addition, added to -fno-stack-protector to case which has disabled the SSP by emptying the SSP_CFLAGS. --- a/lib/csu/Makefile.inc +++ b/lib/csu/Makefile.inc -SSP_CFLAGS= +SSP_CFLAGS= -fno-stack-protector > And -fstack-protector-strong should work in general on freebsd. They even > backported it to 4.8 IIRC. System compiler is gcc-4.2.1 or clang on vanilla FreeBSD. Kernel and core components of vanilla FreeBSD is built using it. Newer version of gcc will be used for FreeBSD's ports. FYI, List containing MK_SSP=no in FreeBSD 10.0 source file. # grep -r MK_SSP * | grep -v != | grep Makefile usr/src/lib/libthr/Makefile:MK_SSP= no usr/src/lib/libstand/Makefile:MK_SSP= no usr/src/tools/bsdbox/Makefile:MK_SSP= no usr/src/rescue/rescue/Makefile:MK_SSP= no usr/src/rescue/librescue/Makefile:MK_SSP= no usr/src/gnu/lib/libgcov/Makefile:MK_SSP= no usr/src/gnu/lib/libssp/Makefile:MK_SSP= no usr/src/gnu/lib/libgcc/Makefile:MK_SSP= no usr/src/gnu/lib/csu/Makefile:MK_SSP= no usr/src/libexec/rtld-elf/Makefile:MK_SSP= no usr/src/sys/boot/powerpc/ofw/Makefile:MK_SSP= no usr/src/sys/boot/powerpc/ps3/Makefile:MK_SSP= no usr/src/sys/boot/userboot/ficl/Makefile:MK_SSP= no usr/src/sys/boot/userboot/userboot/Makefile:MK_SSP= no usr/src/sys/boot/userboot/libstand/Makefile:MK_SSP= no usr/src/sys/boot/userboot/test/Makefile:MK_SSP= no usr/src/sys/boot/sparc64/loader/Makefile:MK_SSP= no usr/src/sys/boot/i386/efi/Makefile:MK_SSP= no usr/src/sys/boot/i386/loader/Makefile:MK_SSP= no usr/src/sys/boot/ia64/common/Makefile:MK_SSP= no usr/src/sys/boot/ia64/efi/Makefile:MK_SSP= no usr/src/sys/boot/ia64/ski/Makefile:MK_SSP= no usr/src/sys/boot/pc98/loader/Makefile:MK_SSP= no
Ah, okay. I misread the patches.
This issue will occur in the version of gcc-4.8.3 or later... -fstack-protector is enabled basically in gcc-4.8.3. If disabled the SSP in Makefile, it is necessary to disable SSP it explicitly by adding -fno-stack-protector. BSD team, Would you please test the patch ? Steps to Reproduce: 1. Install gcc-4.8.3 and set 4.8.3 using gcc-config 2. emerge freebsd-libexec Results: >>> Installing (1 of 1) sys-freebsd/freebsd-libexec-9.1-r2 * Removing /usr/lib/systemd * >>> SetUID: [chmod go-r] /usr/libexec/ulog-helper ... [ ok ] stack overflow detected; terminated !!! FAILED prerm: 1 stack overflow detected; terminated <snip> * Messages for package sys-freebsd/freebsd-libexec-9.1-r2: * QA: Kernel version could not be determined, please inherit kernel-2 or linux-info * QA: Kernel version could not be determined, please inherit kernel-2 or linux-info * The ebuild phase 'postinst' has exited unexpectedly. This type of * behavior is known to be triggered by things such as failed variable * assignments (bug #190128) or bad substitution errors (bug #200313). * Normally, before exiting, bash should have displayed an error message * above. If bash did not produce an error message above, it's possible * that the ebuild has called `exit` when it should have called `die` * instead. This behavior may also be triggered by a corrupt bash binary or * a hardware problem such as memory or cpu malfunction. If the problem is * not reproducible or it appears to occur randomly, then it is likely to * be triggered by a hardware problem. If you suspect a hardware problem * then you should try some basic hardware diagnostics such as memtest. * Please do not report this as a bug unless it is consistently * reproducible and you are sure that your bash binary and hardware are * functioning properly. * The ebuild phase 'other' has exited unexpectedly. This type of behavior * is known to be triggered by things such as failed variable assignments * (bug #190128) or bad substitution errors (bug #200313). Normally, before * exiting, bash should have displayed an error message above. If bash did * not produce an error message above, it's possible that the ebuild has * called `exit` when it should have called `die` instead. This behavior * may also be triggered by a corrupt bash binary or a hardware problem * such as memory or cpu malfunction. If the problem is not reproducible or * it appears to occur randomly, then it is likely to be triggered by a * hardware problem. If you suspect a hardware problem then you should try * some basic hardware diagnostics such as memtest. Please do not report * this as a bug unless it is consistently reproducible and you are sure * that your bash binary and hardware are functioning properly. # ls stack overflow detected; terminated
FYI, /usr/portage/metadata/news/2014-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt @toolchain, Please add the following line. This news will be displayed on Gentoo/FreeBSD. Display-If-Keyword: amd64-fbsd Display-If-Keyword: x86-fbsd
Created attachment 380664 [details, diff] boot0-add-nossp-cflags.patch patch for boot0.
9.3 and 10.0 was fixed in gentoo-bsd overlay. http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git;a=commitdiff;h=2bed8a28bd11a8591d938ed885567cbb712cac32
(In reply to Yuta SATOH from comment #9) > FYI, > /usr/portage/metadata/news/2014-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt > > @toolchain, > Please add the following line. > This news will be displayed on Gentoo/FreeBSD. > > Display-If-Keyword: amd64-fbsd > Display-If-Keyword: x86-fbsd Done.
so what is left to do here ?
(In reply to SpanKY from comment #13) > so what is left to do here ? @bsd, need to apply patches (Attachments #379018, #379020, #380664).
+ 18 Feb 2015; Michał Górny <mgorny@gentoo.org> + +files/boot0-add-nossp-cflags.patch, boot0-9.1.ebuild, boot0-9.2.ebuild: + Fix SIGABRT failure when compiled with SSP-enabled gcc, bug #511698, patch by + Yuta SATOH + 18 Feb 2015; Michał Górny <mgorny@gentoo.org> + +files/freebsd-lib-add-nossp-cflags.patch, freebsd-lib-9.1-r11.ebuild, + freebsd-lib-9.2.ebuild: + Fix SIGABRT failure when compiled with SSP-enabled gcc, bug #511698, patch by + Yuta SATOH + 18 Feb 2015; Michał Górny <mgorny@gentoo.org> + +files/freebsd-mk-defs-add-nossp-cflags.patch, freebsd-mk-defs-9.1.ebuild, + freebsd-mk-defs-9.2.ebuild: + Fix SIGABRT failure when compiled with SSP-enabled gcc, bug #511698, patch by + Yuta SATOH
