public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: gcc-patches@gcc.gnu.org
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Subject: [RS6000] Power10 libffi fixes
Date: Tue, 22 Sep 2020 10:00:11 +0930	[thread overview]
Message-ID: <20200922003011.GB5452@bubble.grove.modra.org> (raw)

Power10 pc-relative code doesn't use or preserve r2 as a TOC pointer.
That means calling between pc-relative and TOC using code can't be
done without intervening linker stubs, and a call from TOC code to
pc-relative code must have a nop after the bl in order to restore r2.

Now the PowerPC libffi assembly code doesn't use r2 except for the
implicit use when making calls back to C, ffi_closure_helper_LINUX64
and ffi_prep_args64.  So changing the assembly to interoperate with
pc-relative code without stubs is easily done.  Controlling that is a
new built-in macro.

Upstream libffi currently has a different patch applied to work around
the power10 build failure.  I'll post a delta for upstream.
Bootstrapped and regression tested on power8, built for power10.

gcc/
	* config/rs6000/rs6000-c.c (rs6000_target_modify_macros):
	Conditionally define __PCREL__.
libffi/
	* src/powerpc/linux64.S (ffi_call_LINUX64): Don't emit global
	entry when __PCREL__.  Call using @notoc.
	(ffi_closure_LINUX64, ffi_go_closure_linux64): Likewise.

diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index f5982907e90..cc1e997524e 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -597,6 +597,9 @@ rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT flags,
   /* Tell the user if we support the MMA instructions.  */
   if ((flags & OPTION_MASK_MMA) != 0)
     rs6000_define_or_undefine_macro (define_p, "__MMA__");
+  /* Whether pc-relative code is being generated.  */
+  if ((flags & OPTION_MASK_PCREL) != 0)
+    rs6000_define_or_undefine_macro (define_p, "__PCREL__");
 }
 
 void
diff --git a/libffi/src/powerpc/linux64.S b/libffi/src/powerpc/linux64.S
index b2ae60ead6e..bfb4d2957ae 100644
--- a/libffi/src/powerpc/linux64.S
+++ b/libffi/src/powerpc/linux64.S
@@ -36,8 +36,10 @@
 	.cfi_startproc
 # if _CALL_ELF == 2
 ffi_call_LINUX64:
+#  ifndef __PCREL__
 	addis	%r2, %r12, .TOC.-ffi_call_LINUX64@ha
 	addi	%r2, %r2, .TOC.-ffi_call_LINUX64@l
+#  endif
 	.localentry ffi_call_LINUX64, . - ffi_call_LINUX64
 # else
 	.section	".opd","aw"
@@ -89,7 +91,11 @@ ffi_call_LINUX64:
 	/* Call ffi_prep_args64.  */
 	mr	%r4, %r1
 # if defined _CALL_LINUX || _CALL_ELF == 2
+#  ifdef __PCREL__
+	bl	ffi_prep_args64@notoc
+#  else
 	bl	ffi_prep_args64
+#  endif
 # else
 	bl	.ffi_prep_args64
 # endif
diff --git a/libffi/src/powerpc/linux64_closure.S b/libffi/src/powerpc/linux64_closure.S
index 6487d2a2970..938e86034f1 100644
--- a/libffi/src/powerpc/linux64_closure.S
+++ b/libffi/src/powerpc/linux64_closure.S
@@ -37,8 +37,10 @@
 	.cfi_startproc
 # if _CALL_ELF == 2
 ffi_closure_LINUX64:
+#  ifndef __PCREL__
 	addis	%r2, %r12, .TOC.-ffi_closure_LINUX64@ha
 	addi	%r2, %r2, .TOC.-ffi_closure_LINUX64@l
+#  endif
 	.localentry ffi_closure_LINUX64, . - ffi_closure_LINUX64
 # else
 	.section        ".opd","aw"
@@ -155,7 +157,11 @@ ffi_closure_LINUX64:
 
 	# make the call
 # if defined _CALL_LINUX || _CALL_ELF == 2
+#  ifdef __PCREL__
+	bl ffi_closure_helper_LINUX64@notoc
+#  else
 	bl ffi_closure_helper_LINUX64
+#  endif
 # else
 	bl .ffi_closure_helper_LINUX64
 # endif
@@ -396,8 +402,10 @@ ffi_closure_LINUX64:
 	.cfi_startproc
 # if _CALL_ELF == 2
 ffi_go_closure_linux64:
+#  ifndef __PCREL__
 	addis	%r2, %r12, .TOC.-ffi_go_closure_linux64@ha
 	addi	%r2, %r2, .TOC.-ffi_go_closure_linux64@l
+#  endif
 	.localentry ffi_go_closure_linux64, . - ffi_go_closure_linux64
 # else
 	.section        ".opd","aw"

-- 
Alan Modra
Australia Development Lab, IBM

             reply	other threads:[~2020-09-22  0:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  0:30 Alan Modra [this message]
2020-09-23  0:16 ` Segher Boessenkool
2020-09-24  3:41   ` Alan Modra
2020-09-24  5:39     ` Alan Modra

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=20200922003011.GB5452@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    /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).