public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Jan Hubicka <hubicka@ucw.cz>,  Uros Bizjak <ubizjak@gmail.com>
Subject: Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases
Date: Wed, 27 Jul 2022 07:31:38 -0700	[thread overview]
Message-ID: <CAMe9rOpp-_Mb9_T=iDQdU0mm8RuZKcGjpk7EZfEnp1HK9VdshQ@mail.gmail.com> (raw)
In-Reply-To: <orr127p27j.fsf@lxoliva.fsfla.org>

On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
>
> g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed,
> have made it clear that there were problems in the optimizations to
> use @GOTOFF to refer to locally-bound ifuncs.  GNU ld as recently as
> May 2018 would reject such constructs, whereas later versions will
> silently accept but generate incorrect PIE with them (attr-ifunc-3.C)
> or still reject them if referenced through aliases (mvc10.c).  The use
> of @GOTOFF for locally-bound but externally-visible symbols
> (e.g. protected visibility) also breaks pointer identity if the
> canonical address ends up preempted by a PLT entry.  This patch
> modifies the local_symbolic_operand predicate to disable @GOTOFF for
> locally-bound symbols that would require @PLT for calls, restoring
> earlier behavior and disabling the optimization that has proven
> problematic even on amd64.  Eventually we may reintroduce the
> optimization, when the linker is fixed and we test for the fix before
> enabling it, and we exclude symbols whose canonical addresses may be
> preempted even when the symbol definition can't.  pr83782 tests have
> been adjusted to expect @GOT instead of @GOTOFF.
>
> Regstrapped on x86_64-linux-gnu; also tested, along with other patches
> I'm posting today with "i386 PIE" in the subject, and compared
> default-PIE and default-nonPIE results on it, and on i686-linux-gnu.  Ok
> to install?

Here is a different fix:

https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html

Use PLT doesn't mean that it can't be treated as local.  The problem
on ia32 is that PIC won't be set up properly for indirect call.    There is
no problem on x86-64 and non-PIC on ia32.

>
> for  gcc/ChangeLog
>
>         PR target/83782
>         * config/i386/predicates.md (local_symbolic_operand): Disable
>         GOTOFF even for locally-bound ifuncs.
>         * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
>         chain looking for an ifunc, as in gcc.target/i386/mvc10.c.
>
> for  gcc/testsuite/ChangeLog
>
>         PR target/83782
>         * gcc.target/i386/pr83782-1.c: Adjust to require GOT rather
>         than GOTOFF on ia32.
>         * gcc.target/i386/pr83782-2.c: Likewise.
> ---
>  gcc/config/i386/i386.cc                   |   16 ++++++++++------
>  gcc/config/i386/predicates.md             |    4 +++-
>  gcc/testsuite/gcc.target/i386/pr83782-1.c |    4 ++--
>  gcc/testsuite/gcc.target/i386/pr83782-2.c |    4 ++--
>  4 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index aab28da4b5d4b..5c5dc8d2373ff 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -16058,13 +16058,17 @@ ix86_call_use_plt_p (rtx call_op)
>      {
>        if (SYMBOL_REF_DECL (call_op)
>           && TREE_CODE (SYMBOL_REF_DECL (call_op)) == FUNCTION_DECL)
> -       {
> -         /* NB: All ifunc functions must be called via PLT.  */
> -         cgraph_node *node
> -           = cgraph_node::get (SYMBOL_REF_DECL (call_op));
> -         if (node && node->ifunc_resolver)
> +       /* NB: All ifunc functions must be called via PLT, and we have
> +          to explicitly iterate over an alias chain looking for a
> +          node marked as an ifunc(_resolver) to tell.  That node is
> +          itself aliased to the actual resolver function, so
> +          ultimate_alias_target would skip the marker, and the call
> +          may be to another declaration aliased to the ifunc.  */
> +       for (cgraph_node *node
> +              = cgraph_node::get (SYMBOL_REF_DECL (call_op));
> +            node && node->alias; node = node->get_alias_target ())
> +         if (node->ifunc_resolver)
>             return true;
> -       }
>        return false;
>      }
>    return true;
> diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
> index 42053ea7209f6..411c06e22e600 100644
> --- a/gcc/config/i386/predicates.md
> +++ b/gcc/config/i386/predicates.md
> @@ -596,7 +596,9 @@ (define_predicate "local_symbolic_operand"
>    if (TARGET_DLLIMPORT_DECL_ATTRIBUTES && SYMBOL_REF_DLLIMPORT_P (op))
>      return false;
>    if (SYMBOL_REF_LOCAL_P (op))
> -    return true;
> +    /* ifuncname@GOTOFF was rejected by the x86 linker before May
> +       2018, and silently generated wrong code for PIE afterwards.  */
> +    return !ix86_call_use_plt_p (op);
>
>    /* There is, however, a not insubstantial body of code in the rest of
>       the compiler that assumes it can just stick the results of
> diff --git a/gcc/testsuite/gcc.target/i386/pr83782-1.c b/gcc/testsuite/gcc.target/i386/pr83782-1.c
> index ce97b12e65d58..af52278ec4df2 100644
> --- a/gcc/testsuite/gcc.target/i386/pr83782-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr83782-1.c
> @@ -20,7 +20,7 @@ bar(void)
>    return foo;
>  }
>
> -/* { dg-final { scan-assembler {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { target ia32 } } } */
> +/* { dg-final { scan-assembler-not {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { target ia32 } } } */
>  /* { dg-final { scan-assembler {lea(?:l|q)[ \t]foo\(%rip\),[ \t]%(?:e|r)ax} { target { ! ia32 } } } } */
> -/* { dg-final { scan-assembler-not "foo@GOT\\\(" { target ia32 } } } */
> +/* { dg-final { scan-assembler "foo@GOT\\\(" { target ia32 } } } */
>  /* { dg-final { scan-assembler-not "foo@GOTPCREL\\\(" { target { ! ia32 } } } } */
> diff --git a/gcc/testsuite/gcc.target/i386/pr83782-2.c b/gcc/testsuite/gcc.target/i386/pr83782-2.c
> index e25d258bbda43..15c7dc04e88c3 100644
> --- a/gcc/testsuite/gcc.target/i386/pr83782-2.c
> +++ b/gcc/testsuite/gcc.target/i386/pr83782-2.c
> @@ -20,7 +20,7 @@ bar(void)
>    return foo;
>  }
>
> -/* { dg-final { scan-assembler {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { target ia32 } } } */
> +/* { dg-final { scan-assembler-not {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { target ia32 } } } */
>  /* { dg-final { scan-assembler {lea(?:l|q)[ \t]foo\(%rip\),[ \t]%(?:e|r)ax} { target { ! ia32 } } } } */
> -/* { dg-final { scan-assembler-not "foo@GOT\\\(" { target ia32 } } } */
> +/* { dg-final { scan-assembler "foo@GOT\\\(" { target ia32 } } } */
>  /* { dg-final { scan-assembler-not "foo@GOTPCREL\\\(" { target { ! ia32 } } } } */
>
> --
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>



-- 
H.J.

  reply	other threads:[~2022-07-27 14:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27  5:13 Alexandre Oliva
2022-07-27 14:31 ` H.J. Lu [this message]
2022-07-28  8:26   ` Alexandre Oliva
2022-07-28 16:31     ` H.J. Lu
2022-08-01 19:03       ` H.J. Lu
2022-08-01 19:15         ` Fangrui Song
2022-08-08 19:29         ` Alexandre Oliva

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='CAMe9rOpp-_Mb9_T=iDQdU0mm8RuZKcGjpk7EZfEnp1HK9VdshQ@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=oliva@adacore.com \
    --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).