Summary: | >=cross-xxx/gcc-4.8.3: defaulting SSP to on for targets that don't support SSP breaks (undefined reference to __stack_chk_guard) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Casper Ti. Vector <CasperVector> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | a1ba.omarov, alex, Bernd.Feige, bertrand, CasperVector, gabemarcano, gentoo_bugs.nu_q5v, luke-jr+gentoobugs, nbowler, pageexec, slyfox, zeekec |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=827923 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 484714 | ||
Attachments: |
build.log.xz
toolchain.eclass.patch |
Description
Casper Ti. Vector
2014-06-18 16:43:00 UTC
Created attachment 379222 [details]
build.log.xz
Same issue here. It seems to only be a problem with i?86, x86_64 works correctly. Note the similar issue in https://bugs.gentoo.org/show_bug.cgi?id=513846 - Here (x86_64 host) all of i686-w64-mingw32, x86_64-w64-mingw32 or i686-pc-mingw32 fail. *** Bug 513846 has been marked as a duplicate of this bug. *** Well, we limit ssp to targets that define TARGET_LIBC_PROVIDES_SSP but... toolchain.eclass: 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(). *** Bug 516384 has been marked as a duplicate of this bug. *** Had the same problem, enabling libssp works. Btw, bug 516354 looks similar to this. (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-26886- ./gcc-4.8.3/gcc/configure:26887:$as_echo "#define TARGET_LIBC_PROVIDES_SSP 1" >>confdefs.h ./gcc-4.8.3/gcc/configure-26888- ./gcc-4.8.3/gcc/configure-26889-fi 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. Created attachment 380668 [details, diff]
toolchain.eclass.patch
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.
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 tocheck=${PIE_UCLIBC_STABLE} else tocheck=${PIE_GLIBC_STABLE} fi elif [[ $1 == "ssp" ]] ; then if [[ ${CTARGET} == *-uclibc* ]] ; then tocheck=${SSP_UCLIBC_STABLE} else tocheck=${SSP_STABLE} fi else die "hardened_gcc_stable needs to be called with pie or ssp" fi 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? 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. (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 *** Bug 516354 has been marked as a duplicate of this bug. *** 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. Fixed in CVS *** Bug 527980 has been marked as a duplicate of this bug. *** |