[libitm] Configure for gas cfi pseudos

Tested on x86_64-linux.  This *ought* to fix RO's Solaris problem.

Committed.


r~
commit 67ba1f57ef6bafdcc0d5e43dbe5793367622977b
Author: rth <rth@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Nov 9 18:09:53 2011 +0000

    libitm: Configure for gas cfi pseudo ops.
    
    	* asmcfi.m4: New file.
    
    	* configure.ac (GCC_AS_CFI_PSEUDO_OP): Test it.
    	* configure, aclocal.m4, config.h.in: Rebuild.
    	* config/generic/asmcfi.h: New file.
    	* config/x86/sjlj.S: Use it.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181224 138bc75d-0d04-0410-961f-82ee72b054a4

Richard Henderson <rth@redhat.com> writes:

> Tested on x86_64-linux.  This *ought* to fix RO's Solaris problem.

Right, that's equivalent to, though cleaner than, what I've done.

There are a few outstanding issues on Solaris/x86 with Sun as:

* as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise osf
  as in config/alpha/sjlj.S):

+#if defined __ELF__ && defined __linux__
 .section .note.GNU-stack, "", @progbits
+#endif

* Sun as apparently cannot handle the branch hints in
  config/x86/cacheline.h (jnz,pn): I've just removed them to get further
  along fof now, but there needs to be a cleaner way, perhaps an
  autoconf test.

* Even if libitm builds now, all execution tests fail like this:

ld.so.1: simple-1.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 ]

  If the code ensures at runtime that AVX insns (or SSE for that matter)
  are only used if hardware and OS are capable of executing them, one
  can deal with this with the equivalent of
  gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so.

  Besides, we need to make sure that the assembler used is able to
  assemble SSE and/or AVX insns before using them.

Thanks.
	Rainer

On 11/09/2011 10:23 AM, Rainer Orth wrote:
> * as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise osf
>   as in config/alpha/sjlj.S):
> 
> +#if defined __ELF__ && defined __linux__
>  .section .note.GNU-stack, "", @progbits
> +#endif

I'll include that in another __ELF__ patch I'm preparing for darwin.

> * Sun as apparently cannot handle the branch hints in
>   config/x86/cacheline.h (jnz,pn): I've just removed them to get further
>   along fof now, but there needs to be a cleaner way, perhaps an
>   autoconf test.

I should just re-write that in __atomic builtins.

> * Even if libitm builds now, all execution tests fail like this:
> 
> ld.so.1: simple-1.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 ]
> 
>   If the code ensures at runtime that AVX insns (or SSE for that matter)
>   are only used if hardware and OS are capable of executing them, one
>   can deal with this with the equivalent of
>   gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so.

Yes, the _M256 entry points will only be used when AVX is used in the compiler.

>   Besides, we need to make sure that the assembler used is able to
>   assemble SSE and/or AVX insns before using them.

I do worry about building a library version missing symbols though...

I suppose we could put them in a different symbol version.  If the
user's program uses them, they'll include that symbol version and
immediately get an ld.so error when moving it to a system that was
built incorrectly.  That's slightly better than a delayed error at
the point that the _M256 gets called and the symbol lookup fails.


r~

On Wed, Nov 09, 2011 at 10:33:12AM -0800, Richard Henderson wrote:
> >   If the code ensures at runtime that AVX insns (or SSE for that matter)
> >   are only used if hardware and OS are capable of executing them, one
> >   can deal with this with the equivalent of
> >   gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so.
> 
> Yes, the _M256 entry points will only be used when AVX is used in the compiler.
> 
> >   Besides, we need to make sure that the assembler used is able to
> >   assemble SSE and/or AVX insns before using them.
> 
> I do worry about building a library version missing symbols though...

Aren't the symbol versions part of the ABI discussed with Intel and others
though?

	Jakub

On 11/09/2011 10:50 AM, Jakub Jelinek wrote:
> Aren't the symbol versions part of the ABI discussed with Intel and others
> though?

Ug.  Probably.  Though they never actually responded wrt the symbol versions
when we talked; none of the guys on the conference call undersood that bit
about how ELF works.

Other options for building a library with missing symbols?


r~

On Wed, 2011-11-09 at 19:50 +0100, Jakub Jelinek wrote:
> On Wed, Nov 09, 2011 at 10:33:12AM -0800, Richard Henderson wrote:
> > >   If the code ensures at runtime that AVX insns (or SSE for that matter)
> > >   are only used if hardware and OS are capable of executing them, one
> > >   can deal with this with the equivalent of
> > >   gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so.
> > 
> > Yes, the _M256 entry points will only be used when AVX is used in the compiler.
> > 
> > >   Besides, we need to make sure that the assembler used is able to
> > >   assemble SSE and/or AVX insns before using them.
> > 
> > I do worry about building a library version missing symbols though...
> 
> Aren't the symbol versions part of the ABI discussed with Intel and others
> though?

This ABI is explicitly for x86 on Linux (we've ignored the Windows
version of it so far). We thus can define it differently (or just offer
a subset of the symbols) on other architectures/platforms.

On 11/09/2011 10:58 AM, Torvald Riegel wrote:
> This ABI is explicitly for x86 on Linux (we've ignored the Windows
> version of it so far). We thus can define it differently (or just offer
> a subset of the symbols) on other architectures/platforms.

Subsets are dangerous.  For any platform that has any kind of support
for AVX, we should simply require it.

For platforms where AVX will never be present (e.g. old OS versions),
I suppose we can add some configury to omit the symbols.


r~

On Wed, Nov 09, 2011 at 10:55:53AM -0800, Richard Henderson wrote:
> On 11/09/2011 10:50 AM, Jakub Jelinek wrote:
> > Aren't the symbol versions part of the ABI discussed with Intel and others
> > though?
> 
> Ug.  Probably.  Though they never actually responded wrt the symbol versions
> when we talked; none of the guys on the conference call undersood that bit
> about how ELF works.
> 
> Other options for building a library with missing symbols?

What exactly are AVX instructions needed for?

Is it just that the entry points get their arguments in %ymm0/%ymm1 etc.
and/or return results in %ymm0?  If so, the poor man's/not very capable
target hack could be to have assembly wrappers for those that would
just vextractf128 the high parts either into some other %xmm registers,
or into memory (using .byte ...) and then call some less optimized C
version of those.

	Jakub

On 11/09/2011 11:03 AM, Jakub Jelinek wrote:
> On Wed, Nov 09, 2011 at 10:55:53AM -0800, Richard Henderson wrote:
>> On 11/09/2011 10:50 AM, Jakub Jelinek wrote:
>>> Aren't the symbol versions part of the ABI discussed with Intel and others
>>> though?
>>
>> Ug.  Probably.  Though they never actually responded wrt the symbol versions
>> when we talked; none of the guys on the conference call undersood that bit
>> about how ELF works.
>>
>> Other options for building a library with missing symbols?
> 
> What exactly are AVX instructions needed for?
> 
> Is it just that the entry points get their arguments in %ymm0/%ymm1 etc.
> and/or return results in %ymm0? 

Yes.

> If so, the poor man's/not very capable
> target hack could be to have assembly wrappers for those that would
> just vextractf128 the high parts either into some other %xmm registers,
> or into memory (using .byte ...) and then call some less optimized C
> version of those.

Ug.  I'm not keen on .byte, but I suppose it's not the worst possibility.
I'll think about that.


r~