From patchwork Wed Sep 12 09:26:50 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 183304 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 566892C0078 for ; Wed, 12 Sep 2012 19:27:20 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1348046841; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=lngbTW94MkhnB7+ytnZu1TJA5tQ=; b=tEQHIkKHE8OwFND 585fAX5ApoYLHODr1PGwhotbocpk9HlQzAwSw2b09alzEmpGVNge57ncotxRWcZs 74PPNBYXKzt+5m6Abu7PAjTqghUvkOVtG65c9dHJrVR7bievPXZfyN0hG8/iRz8h URsc2Sl3HjNxoqsgi96LwydMz0uA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=lJXVZUmh47rbDOZZXbnch8MKfU4KIMZvuJ9z/KnZdQg8z695v4fYBZTfwGmIeT KlQR9ePkqybAOh6Tcywmmpa9M0xbUiBmd3TAa0uXWd6gHpkH1x2VH3CLzJdeLKR3 IbwsV5qgTbClew9pW7TazxEhYN+p/ozjaXrTNagnlaLAA=; Received: (qmail 14640 invoked by alias); 12 Sep 2012 09:27:12 -0000 Received: (qmail 14625 invoked by uid 22791); 12 Sep 2012 09:27:10 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Sep 2012 09:26:56 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 7F3B9E19; Wed, 12 Sep 2012 11:26:54 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HBvozNjg8WFP; Wed, 12 Sep 2012 11:26:50 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id CF38AE15; Wed, 12 Sep 2012 11:26:50 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.5+Sun/8.14.5/Submit) id q8C9Qo5v007103; Wed, 12 Sep 2012 11:26:50 +0200 (MEST) From: Rainer Orth To: gcc-patches@gcc.gnu.org Cc: libstdc++@gcc.gnu.org, Paolo Bonzini Subject: [v3, build] Clear hardware capabilities on libstdc++.so with Sun as Date: Wed, 12 Sep 2012 11:26:50 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (usg-unix-v) MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Since the use of rdrand was introduced in src/c++11/random.cc, all execution tests involving libstdc++.so.6 fail on Solaris 10 and 11/x86 with a sufficiently recent native assembler that supports rdrand: either Solaris 10/x86 patch 119961-11 or Solaris 11.1 builds (haven't checked which one). The problem is that as tags src/c++11/random.o as needing RDRAND support: % file random.o random.o: ELF 32-bit LSB relocatable 80386 Version 1 [CMOV RDRAND] which is propagated to libstdc++.so.6 and causes the runtime linker to fail the execution if the hardware doesn't support that hardware capability, although rdrand is executed only if the cpuid indicates the support is present. The usual solution so far has been to clear the hardware capability using a linker map (as in libitm, cf. libitm/clearcap.map). Unfortunately, this doesn't work here: as can be seen with elfdump, RDRAND is set in a second mask (CA_SUNW_HW_2) since all bits in CA_SUNW_HW_1 are already used: % elfdump -H random.o Capabilities Section: .SUNW_cap Object Capabilities: index tag value [0] CA_SUNW_HW_1 0x20 [ CMOV ] [1] CA_SUNW_HW_2 0x1 [ RDRAND ] The old (v1) linker map syntax has no support for clearing that bit/mask, and while the v2 map syntax does, we cannot universally assume it's present on Solaris 10: while recent linker patches include it, older ones don't and ld and as can be updated independently. So I've settled for a different solution instead: Sun assemblers with hardware capability support also have a -nH switch to suppress their generation, thus I'm testing for that and use it if possible. This is exactly what the following patch does. Bootstrapped without regressions on i386-pc-solaris2.1[01] with affected versions of Sun as and gas 2.22. Results with gas are unchanged, with Sun as all failures are gone. x86_64-unknown-linux-gnu bootstrap is running to make sure nothing breaks there. Ok for mainline if that passes? Rainer 2012-09-11 Rainer Orth * acinclude.m4 (GLIBCXX_CHECK_ASSEMBLER_HWCAP): Define. * configure.ac: Call GLIBCXX_CHECK_ASSEMBLER_HWCAP. * fragment.am (CONFIG_CXXFLAGS): Add $(HWCAP_FLAGS). * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. # HG changeset patch # Parent cc6aab46be72c37bfdfccd786ed5c332a7ce4cd9 Clear hardware capabilities on libstdc++.so with Sun as diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -169,6 +169,32 @@ AC_DEFUN([GLIBCXX_CHECK_COMPILER_FEATURE dnl +dnl Check if the assembler used supports disabling generation of hardware +dnl capabilities. This is only supported by Sun as at the moment. +dnl +dnl Defines: +dnl HWCAP_FLAGS='-Wa,-nH' if possible. +dnl +AC_DEFUN([GLIBCXX_CHECK_ASSEMBLER_HWCAP], [ + test -z "$HWCAP_FLAGS" && HWCAP_FLAGS='' + + ac_save_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS -Wa,-nH" + + AC_MSG_CHECKING([for as that supports -Wa,-nH]) + AC_TRY_COMPILE([], [return 0;], [ac_hwcap_flags=yes],[ac_hwcap_flags=no]) + if test "$ac_hwcap_flags" = "yes"; then + HWCAP_FLAGS="-Wa,-nH $HWCAP_FLAGS" + fi + AC_MSG_RESULT($ac_hwcap_flags) + + CFLAGS="$ac_save_CFLAGS" + + AC_SUBST(HWCAP_FLAGS) +]) + + +dnl dnl If GNU ld is in use, check to see if tricky linker opts can be used. If dnl the native linker is in use, all variables will be defined to something dnl safe (like an empty string). diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -333,6 +333,9 @@ case "$target" in esac GLIBCXX_CONDITIONAL(GLIBCXX_LDBL_COMPAT, test $ac_ldbl_compat = yes) +# Check if assembler supports disabling hardware capability support. +GLIBCXX_CHECK_ASSEMBLER_HWCAP + # Check if assembler supports rdrand opcode. GLIBCXX_CHECK_X86_RDRAND diff --git a/libstdc++-v3/fragment.am b/libstdc++-v3/fragment.am --- a/libstdc++-v3/fragment.am +++ b/libstdc++-v3/fragment.am @@ -22,7 +22,7 @@ endif # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ + $(SECTION_FLAGS) $(HWCAP_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR_FLAG) -fdiagnostics-show-location=once