Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 513706 - >=cross-xxx/gcc-4.8.3: defaulting SSP to on for targets that don't support SSP breaks (undefined reference to __stack_chk_guard)
Summary: >=cross-xxx/gcc-4.8.3: defaulting SSP to on for targets that don't support SS...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
: 513846 516354 516384 527980 (view as bug list)
Depends on:
Blocks: 484714
  Show dependency tree
Reported: 2014-06-18 16:43 UTC by Casper Ti. Vector
Modified: 2021-12-01 00:32 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---

build.log.xz (build.log.xz,47.84 KB, application/x-xz)
2014-06-18 16:44 UTC, Casper Ti. Vector
toolchain.eclass.patch (toolchain.eclass.patch,607 bytes, patch)
2014-07-13 07:43 UTC, Gabriel Marcano
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Casper Ti. Vector 2014-06-18 16:43:00 UTC
cross-i686-pc-mingw32/gcc-4.8.3 fails to build because of undefined reference to `__stack_chk_guard' and `__stack_chk_fail'.

Reproducible: Always

Steps to Reproduce:
1. # emerge '=sys-devel/gcc-4.8.3'
2. # emerge '=cross-i686-pc-mingw32/gcc-4.8.3'
Actual Results:  
cross-i686-pc-mingw32/gcc-4.8.3 fails to build.

Expected Results:  
cross-i686-pc-mingw32/gcc-4.8.3 builds successfully.

Portage 2.2.10 (default/linux/amd64/13.0/desktop, gcc-4.8.3, glibc-2.19-r1, 3.15.0-gentoo-r1 x86_64)
                        System Settings
System uname: Linux-3.15.0-gentoo-r1-x86_64-Intel-R-_Core-TM-_i7-3720QM_CPU_@_2.60GHz-with-gentoo-2.2
KiB Mem:     7995584 total,    503520 free
KiB Swap:    8388604 total,   8388208 free
Timestamp of tree: Wed, 18 Jun 2014 13:15:01 +0000
ld GNU ld (GNU Binutils) 2.24
app-shells/bash:          4.2_p47
dev-java/java-config:     2.2.0
dev-lang/python:          2.7.6-r1, 3.3.5, 3.4.0
dev-util/pkgconfig:       0.28-r1
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.10.3, 1.11.6, 1.14.1
sys-devel/binutils:       2.24-r3
sys-devel/gcc:            4.8.3
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2-r1
sys-devel/make:           4.0-r1
sys-kernel/linux-headers: 3.15 (virtual/os-headers)
sys-libs/glibc:           2.19-r1
Repositories: gentoo gentoo-zh gentoo-haskell crossdev caspervector
ACCEPT_KEYWORDS="amd64 ~amd64"
CFLAGS="-march=core-avx-i -O2 -pipe"
CONFIG_PROTECT="/etc /usr/share/easy-rsa /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=core-avx-i -O2 -pipe"
EMERGE_DEFAULT_OPTS="--with-bdeps=y --keep-going=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs cgroup compressdebug config-protect-if-modified distlocks ebuild-locks fakeroot fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg"
FFLAGS="-O2 -pipe"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/var/lib/layman/gentoo-zh /var/lib/layman/haskell /usr/crossdev/portage /usr/local/portage"
USE="X a52 aac acl acpi alsa amd64 bash-completion berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cxx dbus dri dts dvd dvdr emboss encode exif fam ffmpeg firefox flac fontconfig fortran geoip gif gnutls gpg gpm gtk gtk3 iconv ipv6 jack jpeg lcms libedit libnotify mad maildir mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds qt3support qt4 readline sdl session smp socks5 sse sse2 sse3 ssl ssse3 startup-notification svg system-sqlite tcpd threads tiff truetype udev udisks unicode upower usb v4l vaapi vorbis wxwidgets x264 xcb xft xinerama xml xv xvid zlib zsh-completion" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

                        Package Settings

sys-devel/gcc-4.8.3 was built with the following:
USE="cxx fortran gcj (multilib) nls nptl openmp (-altivec) -awt -doc (-fixed-point) -go -graphite (-hardened) (-libssp) -mudflap (-multislot) -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" ABI_X86="64"

cross-i686-pc-mingw32/gcc-4.8.2 was built with the following:
USE="cxx fortran nls nptl openmp (-altivec) -awt -doc (-fixed-point) -gcj -go -graphite -hardened -libssp -mudflap -multilib -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" ABI_X86="64"
CFLAGS="-O2 -pipe"
Comment 1 Casper Ti. Vector 2014-06-18 16:44:39 UTC
Created attachment 379222 [details]
Comment 2 Alex Barker 2014-06-19 14:38:04 UTC
Same issue here. It seems to only be a problem with i?86, x86_64 works correctly.
Comment 3 Bernd Feige 2014-06-23 15:45:47 UTC
Note the similar issue in - Here (x86_64 host) all of i686-w64-mingw32, x86_64-w64-mingw32 or i686-pc-mingw32 fail.
Comment 4 SpanKY gentoo-dev 2014-06-24 21:29:50 UTC
*** Bug 513846 has been marked as a duplicate of this bug. ***
Comment 5 Ryan Hill (RETIRED) gentoo-dev 2014-06-25 04:53:30 UTC
Well, we limit ssp to targets that define TARGET_LIBC_PROVIDES_SSP but...

1133         if use_if_iuse libssp ; then
1134             confgcc+=( --enable-libssp )
1135         else
1136             export gcc_cv_libc_provides_ssp=yes
1137             confgcc+=( --disable-libssp )
1138         fi

If we can't change that maybe we can do some target checking in hardened_gcc_works().
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2014-07-04 19:33:20 UTC
*** Bug 516384 has been marked as a duplicate of this bug. ***
Comment 7 Mario Kicherer 2014-07-08 13:03:46 UTC
Had the same problem, enabling libssp works. Btw, bug 516354 looks similar to this.
Comment 8 Gabriel Marcano 2014-07-13 04:43:43 UTC
(In reply to Mario Kicherer from comment #7)
> Had the same problem, enabling libssp works. Btw, bug 516354 looks similar
> to this.

I think it's also a duplicate. I posted there a bit of my experimentation. In summary, tweaking gcc_do_filter_flags() in toolkit.eclass for the CFLAGS and CXXFLAGS in the cross-compilation conditional to include -fno-stack-protector makes the compilation succeed. This makes sense because this forces the stack checking to be turned off (rather forcibly). Not that I recommend anyone do this, just mentioning this because this further asserts the problem being discussed.

I may be stating the obvious for some, but as Ryan Hill highlighted in comment 5, not having the libssp useflag selected sets the variable gcc_cv_libc_provides_ssp to yes. A quick grep of the GCC working folder (after a failed compilation) revealed the following:

./gcc-4.8.3/gcc/configure-26885-if test x$gcc_cv_libc_provides_ssp = xyes; then
./gcc-4.8.3/gcc/configure:26887:$as_echo "#define TARGET_LIBC_PROVIDES_SSP 1" 

Setting this variable to yes makes configure think that the TARGET supports ssp, which, as I'm understanding this bug, is not the case with mingw cross-compilers. I'm not sure what the best course of action is, but I'm almost sure that the current setting of the gcc_cv_libc_provides_ssp variable in toolkit.eclass needs more processing/checking. Forgive my ignorance, but is it possible to check for TARGET_LIBC_PROVIDES_SSP in toolkit.eclass for the desired TARGET, and if it is already set, then enable gcc_cv_libc_provides_ssp? I'm going to keep poking at this to see if I can do anything else.
Comment 9 Gabriel Marcano 2014-07-13 07:43:39 UTC
Created attachment 380668 [details, diff]

Patch making hardened_gcc_is_stable ssp return 1 only if all previous tests pass, plus the C library in the system is gnu* or uclibc* . Also uses hardened_gcc_is_stable ssp in a conditional to set gcc_cv_libc_provides_ssp to yes only if hardened_gcc_is_stable ssp returns true.
Comment 10 Gabriel Marcano 2014-07-13 07:48:02 UTC
Further prodding in toolchain.eclass.

toolchain_src_prepare() calls make_gcc_hard() for gcc versions 4.8.3 and above (with some other conditions, see the eclass for details), which then calls hardened_gcc_works ssp if the hardened useflag is missing (which is the case on my system). hardened_gcc_works ssp then later calls hardened_gcc_is_stable ssp, which I'm copying here for ease of access:
    hardened_gcc_is_stable() {
        local tocheck
        if [[ $1 == "pie" ]] ; then
            if [[ ${CTARGET} == *-uclibc* ]] ; then
        elif [[ $1 == "ssp" ]] ; then
            if [[ ${CTARGET} == *-uclibc* ]] ; then
            die "hardened_gcc_stable needs to be called with pie or ssp"

        has $(tc-arch) ${tocheck} && return 0
        return 1

I think hardened_gcc_is_stable() is incomplete. All it does is if the architecture prefix being targeted supports SSP (for my cross-compiler, x86_64-w64-mingw32 is the full CTARGET, so it parses only the x86_64 and translates it to amd64, which then is checked for its existence in ${tocheck} by using has()). The thing is, in my case, just because my architecture prefix is amd64 doesn't mean that SSP is supported. If CTARGET were my CHOST (x86_64-pc-linux-gnu), sure, but not with CTARGET="x86_64-w64-mingw32", which doesn't have ssp built into its C libraries by default (if I understand correctly).

(Assuming I'm right about hardened_gcc_is_stable()) If we fix hardened_gcc_is_stable(), we could then use it in the bit mentioned in comment 5 to check if SSP is supported. In the case that it is not, we don't set gcc_cv_libc_provides_ssp=yes.

I can't think of a way to check reasonably if SSP could be supported in the CTARGET system automatically, other than using a whitelist of some sort. I'm currently looking for a list of C libraries that can be configured to have SSP (so far, I've only found that Glibc, and uClibc have this built in) to make into some sort of whitelist.

Taking all of this comment into account, I've come up with a patch for toolchain.eclass that tries to tackle the problem in the manner I've been describing. I've tested this on my system and I can verify that the mingw cross-compiler compiles fine with no apparent mention of SSP, and another cross-compiler (armv6zk-hardfloat-linux-gnueabihf, using gnu* C libraries) compiles fine, and its config logs still have traces of SSP (specifically, "#define TARGET_LIBC_PROVIDES_SSP 1"). Thoughts?
Comment 11 Ryan Hill (RETIRED) gentoo-dev 2014-07-18 05:15:19 UTC
Yes, that's pretty much what I was getting at.  Your patch looks okay, but I'd like to know why we started forcing TARGET_LIBC_PROVIDES_SSP on and if there's still a reason for it.
Comment 12 Magnus Granberg gentoo-dev 2014-07-29 23:04:31 UTC
(In reply to Ryan Hill from comment #11)
> Yes, that's pretty much what I was getting at.  Your patch looks okay, but
> I'd like to know why we started forcing TARGET_LIBC_PROVIDES_SSP on and if
> there's still a reason for it.
I think we can remove the forcing of ARGET_LIBC_PROVIDES_SSP
It looks like it something left from the old times.
The patch looks okay
Comment 13 SpanKY gentoo-dev 2014-07-30 08:54:28 UTC
*** Bug 516354 has been marked as a duplicate of this bug. ***
Comment 14 SpanKY gentoo-dev 2014-07-30 09:28:12 UTC
we still should have a USE=ssp flag imo.  people generating cross-compilers have a better idea of what sane defaults should be for their system than forcing ssp on all the time.
Comment 15 Magnus Granberg gentoo-dev 2014-08-04 23:04:23 UTC
Fixed in CVS
Comment 16 SpanKY gentoo-dev 2015-05-05 06:48:22 UTC
*** Bug 527980 has been marked as a duplicate of this bug. ***