Bug 20662: checking whether x86_64-pc-linux-gnu-gcc implicitly enables -fstack-protector no (32bit gcc 6.2.0 pie and ssp enable)
Commit Message
When glibc get compile with gcc 6.2 that have been configured with
--enable-default-pie and --enable-default-ssp. The check that check if the
compiler use -fstack-protector as default fail on the 32bit part.
checking for libgd... no
checking for _FORTIFY_SOURCE predefine... yes
checking whether x86_64-pc-linux-gnu-gcc -m32 -Wl,-O1 -Wl,--as-needed
implicitly enables -fstack-protector... no
checking whether the linker provides working __ehdr_start... yes
This patch make so we look for __stack_chk_fail_local in the check.
Tested on x86_64 multilib Gentoo
Changelog:
2016-10-20 Magnus Granberg <zorry@gentoo.org>
Denis Kaganovich <mahatma@eu.by>
* configure.ac:
Add check for __stack_chk_fail_local in libc_cv_predef_stack_protector
check.
* configure: Regenerated.
---
Comments
On 20/10/16 21:01, Magnus Granberg wrote:
> When glibc get compile with gcc 6.2 that have been configured with
> --enable-default-pie and --enable-default-ssp. The check that check if the
> compiler use -fstack-protector as default fail on the 32bit part.
>
i'm not against this patch, just note that any reasonable ssp
implementation would not make a call in case of failure, but
crash the application immediately, i hope gcc will have an
option in the future to do that, which means this check will
not work (the test would have to look for canary access, which
is target specific).
fredag 21 oktober 2016 kl. 09:58:08 CEST skrev Szabolcs Nagy:
> On 20/10/16 21:01, Magnus Granberg wrote:
> > When glibc get compile with gcc 6.2 that have been configured with
> >
> > --enable-default-pie and --enable-default-ssp. The check that check if
> > the
> >
> > compiler use -fstack-protector as default fail on the 32bit part.
>
> i'm not against this patch, just note that any reasonable ssp
> implementation would not make a call in case of failure, but
> crash the application immediately, i hope gcc will have an
> option in the future to do that, which means this check will
> not work (the test would have to look for canary access, which
> is target specific).
Thanks
thanks, i cleaned it up a bit and pushed it to master & 2.23 & 2.24
-mike
@@ -1667,12 +1668,14 @@ echo >&AS_MESSAGE_LOG_FD "libc_undefs='$libc_undefs'"
# symbols (resolved by the linker), so filter out unknown symbols.
# This will fail to produce the correct result if the compiler
# defaults to -fstack-protector but this produces an undefined symbol
-# other than __stack_chk_fail. However, compilers like that have not
-# been encountered in practice.
-libc_undefs=`echo "$libc_undefs" | egrep '^(foobar|__stack_chk_fail)$'`
+# other than __stack_chk_fail or __stack_chk_fail_local. However,
+# compilers like that have not been encountered in practice.
+libc_undefs=`echo "$libc_undefs" | \
+ egrep '^(foobar|__stack_chk_fail|__stack_chk_fail_local)$'`
case "$libc_undefs" in
foobar) libc_cv_predef_stack_protector=no ;;
'__stack_chk_fail
+foobar'|'__stack_chk_fail_local
foobar') libc_cv_predef_stack_protector=yes ;;
*) AC_MSG_ERROR([unexpected symbols in test: $libc_undefs]) ;;
esac],