[libitm, build] Clear hardware capabilities on libitm.so with Sun ld

[Rainer Orth]

Richard Henderson <rth@redhat.com> writes:

> On 11/21/2011 05:53 AM, Rainer Orth wrote:
>> The libitm execution tests are currently failing on Solaris 10 and up
>> with Sun as/ld:
>> 
>> ld.so.1: cancel.exe: fatal: /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libitm/.libs/libitm.so.0: hardware capability (CA_SUNW_HW_1) unsupported: 0x20000000  [ AVX ]
>> FAIL: libitm.c/cancel.c execution test
>> 
>> This is the same issue solved by
>> gcc/testsuite/gcc.target/i386/clearcap.map, and the following patch
>> adresses it in the same way:
>> 
>> * Detect if the linker used supports -M <map file>.
>> 
>> * Use it when linking libitm.so.
>> 
>> Right now, it is only possible to clear the hardware capabilities
>> completely, while the new v2 mapfile syntax supports selectively adding
>> and removing capabilities.  It is only available in Solaris 11 and
>> Solaris 10 Update 10, though, so I'm restricting us to the v1 syntax for
>> now.
>
> This is only ok if the compiler and library are build with default options.
> If you use --with-arch=corei7-avx then we may well use AVX insns all through
> the library, not just in the one interface that will only be used if the 
> user of the library is using avx.
>
> Can you auto-foo this based on CC+CFLAGS?  E.g.  compile-time tests for the
> various __SSE__ / __AVX__ macros?

My first attempt was to apply the equivalent of ld -r -M clearcap.map to
x86_avx.lo and x86_sse.lo.  While this works fine if calling ld -r
directly, you need to get this through libtool and this is where things
start breaking in all sorts of ways:

I tried

      $ libtool --mode=link --tag=CC gcc -r -Wl,-M,clearcap.map -o x86_nhc.lo x86_sse.lo
      libtool: link: collect-ld -r -o x86_nhc.o  .libs/x86_sse.o  
      libtool: link: collect-ld -r -o x86_nhc.lo .libs/x86_sse.o 

This is of no use at all since -Wl,-M,clearcap.map is lost completely
and I've found no way to get this through libtool at all.  This beast
tries to be smart and messes everything up completely.  But even if I
could get that part to work, what happens is still wrong: the .lo file
is a real object file now, not the usual text file, so once I try to
link the shared lib, libtool rightly complains.  While the libtool docs
claim that this relinking (.lo -> .lo) should work, it obviously does
not, even with libtool 2.2.4 ;-(

So unless I'm overlooking something, I'll have to go the route you
outlined above and check for __SSE__/__AVX__ to make the decision.

	Rainer

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