* Re: [v3, build] Clear hardware capabilities on libstdc++.so with Sun as
@ 2012-12-01 21:40 David Edelsohn
0 siblings, 0 replies; 3+ messages in thread
From: David Edelsohn @ 2012-12-01 21:40 UTC (permalink / raw)
To: Rainer Orth; +Cc: GCC Patches, libstdc++, Paolo Bonzini
Rainer,
This patch is completely wrong and unacceptable because your test
applies too generally. Why, exactly, is it appropriate to assume that
the "-nH" assembler command line option means the same thing on all
systems and one wants to clear HW capabilities on all systems?
Because it is not appropriate and does not mean the same thing on AIX,
for example.
If you want to test the feature on Solaris, then test it on Solaris
and Solaris only.
Please fix this or revert it.
Thanks, David
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [v3, build] Clear hardware capabilities on libstdc++.so with Sun as
2012-09-12 9:27 Rainer Orth
@ 2012-09-12 11:27 ` Paolo Bonzini
0 siblings, 0 replies; 3+ messages in thread
From: Paolo Bonzini @ 2012-09-12 11:27 UTC (permalink / raw)
To: Rainer Orth; +Cc: gcc-patches, libstdc++
Il 12/09/2012 11:26, Rainer Orth ha scritto:
> 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 <ro@CeBiTec.Uni-Bielefeld.DE>
>
> * 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.
>
>
>
>
Ok.
Paolo
^ permalink raw reply [flat|nested] 3+ messages in thread
* [v3, build] Clear hardware capabilities on libstdc++.so with Sun as
@ 2012-09-12 9:27 Rainer Orth
2012-09-12 11:27 ` Paolo Bonzini
0 siblings, 1 reply; 3+ messages in thread
From: Rainer Orth @ 2012-09-12 9:27 UTC (permalink / raw)
To: gcc-patches; +Cc: libstdc++, Paolo Bonzini
[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]
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 <ro@CeBiTec.Uni-Bielefeld.DE>
* 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.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: solx86-libstdc++-hwcap.patch --]
[-- Type: text/x-patch, Size: 2147 bytes --]
# 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
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-12-01 21:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-01 21:40 [v3, build] Clear hardware capabilities on libstdc++.so with Sun as David Edelsohn
-- strict thread matches above, loose matches on Subject: below --
2012-09-12 9:27 Rainer Orth
2012-09-12 11:27 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).