This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3, build] Clear hardware capabilities on libstdc++.so with Sun as
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Wed, 12 Sep 2012 13:27:18 +0200
- Subject: Re: [v3, build] Clear hardware capabilities on libstdc++.so with Sun as
- References: <yddehm7twv9.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
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