Patchwork [libitm] Configure for gas cfi pseudos

login
register
mail settings
Submitter Richard Henderson
Date Nov. 9, 2011, 6:11 p.m.
Message ID <4EBAC259.1090002@redhat.com>
Download mbox | patch
Permalink /patch/124649/
State New
Headers show

Comments

Richard Henderson - Nov. 9, 2011, 6:11 p.m.
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
Rainer Orth - Nov. 9, 2011, 6:23 p.m.
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
Richard Henderson - Nov. 9, 2011, 6:33 p.m.
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~
Jakub Jelinek - Nov. 9, 2011, 6:50 p.m.
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
Richard Henderson - Nov. 9, 2011, 6:55 p.m.
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~
Torvald Riegel - Nov. 9, 2011, 6:58 p.m.
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.
Richard Henderson - Nov. 9, 2011, 7:02 p.m.
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~
Jakub Jelinek - Nov. 9, 2011, 7:03 p.m.
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
Richard Henderson - Nov. 9, 2011, 7:04 p.m.
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~

Patch

diff --git a/config/ChangeLog b/config/ChangeLog
index 7737f99..4f202ff 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,7 @@ 
+2011-11-09  Richard Henderson  <rth@redhat.com>
+
+	* asmcfi.m4: New file.
+
 2011-11-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
 
 	* mh-interix (LIBGCC2_DEBUG_CFLAGS): Remove.
diff --git a/config/asmcfi.m4 b/config/asmcfi.m4
new file mode 100644
index 0000000..a725aa1
--- /dev/null
+++ b/config/asmcfi.m4
@@ -0,0 +1,15 @@ 
+;; Cribbed from libffi
+
+AC_DEFUN([GCC_AS_CFI_PSEUDO_OP],
+[AC_CACHE_CHECK([assembler .cfi pseudo-op support],
+    gcc_cv_as_cfi_pseudo_op, [
+    gcc_cv_as_cfi_pseudo_op=unknown
+    AC_TRY_COMPILE([asm (".cfi_startproc\n\t.cfi_endproc");],,
+		   [gcc_cv_as_cfi_pseudo_op=yes],
+		   [gcc_cv_as_cfi_pseudo_op=no])
+ ])
+ if test "x$gcc_cv_as_cfi_pseudo_op" = xyes; then
+    AC_DEFINE(HAVE_AS_CFI_PSEUDO_OP, 1,
+	      [Define if your assembler supports .cfi_* directives.])
+ fi
+])
diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index fe1d7d0..e91f91e 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,3 +1,10 @@ 
+2011-11-09  Richard Henderson  <rth@redhat.com>
+
+	* 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.
+
 2011-11-08  Richard Henderson  <rth@redhat.com>
 
 	* local.cc (_ITM_LB): Use a normal call, not a function alias.
diff --git a/libitm/aclocal.m4 b/libitm/aclocal.m4
index 6dcccdf..96617e6 100644
--- a/libitm/aclocal.m4
+++ b/libitm/aclocal.m4
@@ -991,6 +991,7 @@  AC_SUBST([am__untar])
 ]) # _AM_PROG_TAR
 
 m4_include([../config/acx.m4])
+m4_include([../config/asmcfi.m4])
 m4_include([../config/depstand.m4])
 m4_include([../config/enable.m4])
 m4_include([../config/futex.m4])
diff --git a/libitm/config.h.in b/libitm/config.h.in
index af13264..369f6c6 100644
--- a/libitm/config.h.in
+++ b/libitm/config.h.in
@@ -6,6 +6,9 @@ 
 /* Define to 1 if the target supports 64-bit __sync_*_compare_and_swap */
 #undef HAVE_64BIT_SYNC_BUILTINS
 
+/* Define if your assembler supports .cfi_* directives. */
+#undef HAVE_AS_CFI_PSEUDO_OP
+
 /* Define to 1 if the target supports __attribute__((alias(...))). */
 #undef HAVE_ATTRIBUTE_ALIAS
 
diff --git a/libitm/config/generic/asmcfi.h b/libitm/config/generic/asmcfi.h
new file mode 100644
index 0000000..fcb45c5
--- /dev/null
+++ b/libitm/config/generic/asmcfi.h
@@ -0,0 +1,44 @@ 
+
+/* Copyright (C) 2011 Free Software Foundation, Inc.
+   Contributed by Richard Henderson <rth@redhat.com>.
+
+   This file is part of the GNU Transactional Memory Library (libitm).
+
+   Libitm is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   Libitm is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include "config.h"
+
+#ifdef HAVE_AS_CFI_PSEUDO_OP
+
+#define cfi_startproc		.cfi_startproc
+#define cfi_endproc		.cfi_endproc
+#define cfi_def_cfa_offset(n)	.cfi_def_cfa_offset n
+#define cfi_def_cfa(r,n)	.cfi_def_cfa r, n
+#define cfi_register(o,n)	.cfi_register o, n
+
+#else
+
+#define cfi_startproc
+#define cfi_endproc
+#define cfi_def_cfa_offset(n)
+#define cfi_def_cfa(r,n)
+#define cfi_register(o,n)
+
+#endif /* HAVE_ASM_CFI */
diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S
index 725ffec..6169499 100644
--- a/libitm/config/x86/sjlj.S
+++ b/libitm/config/x86/sjlj.S
@@ -22,18 +22,21 @@ 
    see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
    <http://www.gnu.org/licenses/>.  */
 
+
+#include "asmcfi.h"
+
 	.text
 	.p2align 4
 	.globl	_ITM_beginTransaction
 	.type	_ITM_beginTransaction, @function
 
 _ITM_beginTransaction:
-	.cfi_startproc
+	cfi_startproc
 #ifdef __x86_64__
 	leaq	8(%rsp), %rax
 	movq	(%rsp), %r8
 	subq	$72, %rsp
-	.cfi_def_cfa_offset 80
+	cfi_def_cfa_offset(80)
 	movq	%rax, (%rsp)
 	movq	%r8, 8(%rsp)
 	movq	%rbx, 16(%rsp)
@@ -45,12 +48,12 @@  _ITM_beginTransaction:
 	movq	%rsp, %rsi
 	call	GTM_begin_transaction
 	addq	$72, %rsp
-	.cfi_def_cfa_offset 8
+	cfi_def_cfa_offset(8)
 	ret
 #else
 	leal	4(%esp), %ecx
 	subl	$28, %esp
-	.cfi_def_cfa_offset 32
+	cfi_def_cfa_offset(32)
 	movl	%ecx, 8(%esp)
 	movl	%ebx, 12(%esp)
 	movl	%esi, 16(%esp)
@@ -59,10 +62,10 @@  _ITM_beginTransaction:
 	leal	8(%esp), %edx
 	call	GTM_begin_transaction
 	addl	$28, %esp
-	.cfi_def_cfa_offset 4
+	cfi_def_cfa_offset(4)
 	ret
 #endif
-	.cfi_endproc
+	cfi_endproc
 	.size	_ITM_beginTransaction, .-_ITM_beginTransaction
 
 	.p2align 4
@@ -71,7 +74,7 @@  _ITM_beginTransaction:
 	.hidden	GTM_longjmp
 
 GTM_longjmp:
-	.cfi_startproc
+	cfi_startproc
 #ifdef __x86_64__
 	movq	(%rdi), %rcx
 	movq	8(%rdi), %rdx
@@ -82,8 +85,8 @@  GTM_longjmp:
 	movq	48(%rdi), %r14
 	movq	56(%rdi), %r15
 	movl	%esi, %eax
-	.cfi_def_cfa %rcx, 0
-	.cfi_register %rip, %rdx
+	cfi_def_cfa(%rcx, 0)
+	cfi_register(%rip, %rdx)
 	movq	%rcx, %rsp
 	jmp	*%rdx
 #else
@@ -94,12 +97,12 @@  GTM_longjmp:
 	movl	12(%edx), %edi
 	movl	16(%edx), %ebp
 	movl	20(%edx), %edx
-	.cfi_def_cfa %ecx, 0
-	.cfi_register %eip, %edx
+	cfi_def_cfa(%ecx, 0)
+	cfi_register(%eip, %edx)
 	movl	%ecx, %esp
 	jmp	*%edx
 #endif
-	.cfi_endproc
+	cfi_endproc
 	.size	GTM_longjmp, .-GTM_longjmp
 
 .section .note.GNU-stack, "", @progbits
diff --git a/libitm/configure b/libitm/configure
index e6bc1aa..0f0ec1f 100644
--- a/libitm/configure
+++ b/libitm/configure
@@ -16908,6 +16908,42 @@  $as_echo "#define LIBITM_GNU_SYMBOL_VERSIONING 1" >>confdefs.h
 
 fi
 
+# See if we can emit unwind info in the sjlj stub.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler .cfi pseudo-op support" >&5
+$as_echo_n "checking assembler .cfi pseudo-op support... " >&6; }
+if test "${gcc_cv_as_cfi_pseudo_op+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+    gcc_cv_as_cfi_pseudo_op=unknown
+    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+asm (".cfi_startproc\n\t.cfi_endproc");
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  gcc_cv_as_cfi_pseudo_op=yes
+else
+  gcc_cv_as_cfi_pseudo_op=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_cfi_pseudo_op" >&5
+$as_echo "$gcc_cv_as_cfi_pseudo_op" >&6; }
+ if test "x$gcc_cv_as_cfi_pseudo_op" = xyes; then
+
+$as_echo "#define HAVE_AS_CFI_PSEUDO_OP 1" >>confdefs.h
+
+ fi
+
+
 # Determine the proper ABI type for size_t.
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking how size_t is mangled" >&5
diff --git a/libitm/configure.ac b/libitm/configure.ac
index dea7038..c40ecb5 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -219,6 +219,9 @@  if test $enable_symvers = gnu; then
 	    [Define to 1 if GNU symbol versioning is used for libitm.])
 fi
 
+# See if we can emit unwind info in the sjlj stub.
+GCC_AS_CFI_PSEUDO_OP
+
 # Determine the proper ABI type for size_t.
 LIBITM_CHECK_SIZE_T_MANGLING