public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: gcc-patches@gcc.gnu.org
Cc: keescook@chromium.org, Ard Biesheuvel <ardb@kernel.org>,
	"H . J . Lu" <hjl.tools@gmail.com>,
	Jakub Jelinek <jakub@redhat.com>,
	Richard Biener <rguenther@suse.de>,
	Uros Bizjak <ubizjak@gmail.com>,
	Hou Wenlong <houwenlong.hwl@antgroup.com>
Subject: [PATCH] i386: Honour -mdirect-extern-access when calling __fentry__
Date: Tue,  9 May 2023 10:58:35 +0200	[thread overview]
Message-ID: <20230509085835.1143661-1-ardb@kernel.org> (raw)

The small and medium PIC code models generate profiling calls that
always load the address of __fentry__() via the GOT, even if
-mdirect-extern-access is in effect.

This deviates from the behavior with respect to other external
references, and results in a longer opcode that relies on linker
relaxation to eliminate the GOT load. In this particular case, the
transformation replaces an indirect 'CALL *__fentry__@GOTPCREL(%rip)'
with either 'CALL __fentry__; NOP' or 'NOP; CALL __fentry__', where the
NOP is a 1 byte NOP that preserves the 6 byte length of the sequence.

This is problematic for the Linux kernel, which generally relies on
-mdirect-extern-access and hidden visibility to eliminate GOT based
symbol references in code generated with -fpie/-fpic, without having to
depend on linker relaxation.

The Linux kernel relies on code patching to replace these opcodes with
NOPs at runtime, and this is complicated code that we'd prefer not to
complicate even more by adding support for patching both 5 and 6 byte
sequences as well as parsing the instruction stream to decide which
variant of CALL+NOP we are dealing with.

So let's honour -mdirect-extern-access, and only load the address of
__fentry__ via the GOT if direct references to external symbols are not
permitted.

Note that the GOT reference in question is in fact a data reference: we
explicitly load the address of __fentry__ from the GOT, which amounts to
eager binding, rather than emitting a PLT call that could bind eagerly,
lazily or directly at link time.

gcc/ChangeLog:

	* config/i386/i386.cc (x86_function_profiler): Take
	  ix86_direct_extern_access into account when generating calls
	  to __fentry__()

Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Richard Biener <rguenther@suse.de>
Cc: Uros Bizjak <ubizjak@gmail.com>
Cc: Hou Wenlong <houwenlong.hwl@antgroup.com>
---
 gcc/config/i386/i386.cc | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index b1d08ecdb3d44729..69b183abb4318b0a 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -21836,8 +21836,12 @@ x86_function_profiler (FILE *file, int labelno ATTRIBUTE_UNUSED)
 	      break;
 	    case CM_SMALL_PIC:
 	    case CM_MEDIUM_PIC:
-	      fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n", mcount_name);
-	      break;
+	      if (!ix86_direct_extern_access)
+		{
+		  fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n", mcount_name);
+		  break;
+		}
+	      /* fall through */
 	    default:
 	      x86_print_call_or_nop (file, mcount_name);
 	      break;
-- 
2.39.2


             reply	other threads:[~2023-05-09  8:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  8:58 Ard Biesheuvel [this message]
2023-05-10  9:16 ` Uros Bizjak
2023-05-10 22:03   ` H.J. Lu
2023-05-11  6:08     ` Uros Bizjak
2023-05-12 14:07       ` Ard Biesheuvel
2023-05-12 17:05         ` Uros Bizjak
2023-05-12 21:56           ` Ard Biesheuvel

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=20230509085835.1143661-1-ardb@kernel.org \
    --to=ardb@kernel.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=houwenlong.hwl@antgroup.com \
    --cc=jakub@redhat.com \
    --cc=keescook@chromium.org \
    --cc=rguenther@suse.de \
    --cc=ubizjak@gmail.com \
    /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).