From: Paolo Bonzini <bonzini@gnu.org>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: [v3, build] Clear hardware capabilities on libstdc++.so with Sun as
Date: Wed, 12 Sep 2012 11:27:00 -0000 [thread overview]
Message-ID: <50507196.9060907@gnu.org> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2012-09-12 11:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 9:27 Rainer Orth
2012-09-12 11:27 ` Paolo Bonzini [this message]
2012-12-01 21:40 David Edelsohn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50507196.9060907@gnu.org \
--to=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).