[v3, build] Clear hardware capabilities on libstdc++.so with Sun as

Rainer Orth ro@CeBiTec.Uni-Bielefeld.DE
Wed Sep 12 09:27:00 GMT 2012


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: solx86-libstdc++-hwcap.patch
Type: text/x-patch
Size: 2147 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20120912/903cce12/attachment.bin>
-------------- next part --------------

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


More information about the Libstdc++ mailing list