Bug 635961 - Don't disable elfhack when the linker creates GNU_RELRO segments. r=froydnj
☠☠ backed out by 6af0ca47efab ☠ ☠
authorMike Hommey <mh+mozilla@glandium.org>
Tue, 11 Jul 2017 08:10:50 +0900
changeset 419639 c56fa9c1eda0243aef35cbb81f105957fff6dd31
parent 419638 ddda63d5366eca8bec018171271fbb426321eab1
child 419640 72c7fc10d21aea0a5bf41b3958ddf3ad57a257b3
push id7566
push usermtabara@mozilla.com
push dateWed, 02 Aug 2017 08:25:16 +0000
treeherdermozilla-beta@86913f512c3c [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersfroydnj
bugs635961
milestone56.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 635961 - Don't disable elfhack when the linker creates GNU_RELRO segments. r=froydnj
old-configure.in
--- a/old-configure.in
+++ b/old-configure.in
@@ -3980,57 +3980,16 @@ if test "$USE_ELF_HACK" = 1; then
         esac
         ;;
     *)
         USE_ELF_HACK=
         ;;
     esac
 fi
 
-if test -n "$COMPILE_ENVIRONMENT" -a -n "$USE_ELF_HACK"; then
-    dnl PT_GNU_RELRO segment makes the dynamic linker set a read-only flag on
-    dnl memory addresses it maps to. The result is that by the time elfhack
-    dnl kicks in, it is not possible to apply relocations because of that,
-    dnl thus elfhack effectively skips relocations inside the PT_GNU_RELRO
-    dnl segment. It makes elfhack mostly useless, so considering the problems
-    dnl we have we PT_GNU_RELRO (e.g. bug 664366), and until elfhack can deal
-    dnl with PT_GNU_RELRO segments, it's just simpler to disable elfhack when
-    dnl the linker creates PT_GNU_RELRO segments. However, when we do want
-    dnl elfhack enabled, disable PT_GNU_RELRO instead.
-    AC_CACHE_CHECK([whether linker creates PT_GNU_RELRO segments],
-        LINK_WITH_PT_GNU_RELRO,
-        [echo "int main() {return 0;}" > conftest.${ac_ext}
-         if AC_TRY_COMMAND(${CC-cc} -o conftest${ac_exeext} $LDFLAGS conftest.${ac_ext} $LIBS 1>&2) &&
-            test -s conftest${ac_exeext}; then
-            if ${TOOLCHAIN_PREFIX}readelf -l conftest${ac_exeext} | grep GNU_RELRO > /dev/null; then
-                LINK_WITH_PT_GNU_RELRO=yes
-            else
-                LINK_WITH_PT_GNU_RELRO=no
-            fi
-         else
-             dnl We really don't expect to get here, but just in case
-             AC_ERROR([couldn't compile a simple C file])
-         fi
-         rm -rf conftest*])
-    if test "$LINK_WITH_PT_GNU_RELRO" = yes; then
-        if test "$USE_ELF_HACK" = F; then
-            AC_MSG_CHECKING([for -z norelro option to ld])
-            _SAVE_LDFLAGS=$LDFLAGS
-            LDFLAGS="$LDFLAGS -Wl,-z,norelro"
-            AC_TRY_LINK(,,AC_MSG_RESULT([yes])
-                        [NSPR_LDFLAGS="$NSPR_LDFLAGS -Wl,-z,norelro"],
-                        AC_ERROR([--enable-elf-hack is not compatible with a linker creating a PT_GNU_RELRO segment and that doesn't support the "-z norelro" option.]))
-            USE_ELF_HACK=1
-        else
-            AC_MSG_WARN([Disabling elfhack])
-            USE_ELF_HACK=
-        fi
-    fi
-fi # COMPILE_ENVIRONMENT and others.
-
 dnl ========================================================
 dnl = libstdc++ compatibility hacks
 dnl ========================================================
 
 STDCXX_COMPAT=
 MOZ_ARG_ENABLE_BOOL(stdcxx-compat,
 [  --enable-stdcxx-compat  Enable compatibility with older libstdc++],
     STDCXX_COMPAT=1)