public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aoliva at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library
Date: Tue, 19 Jul 2022 03:42:07 +0000	[thread overview]
Message-ID: <bug-83782-4-1syZusBWau@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-83782-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I'm running into some problems that are related with this PR.

First off, on i686-linux-gnu with --enable-default-pie, attr-ifunc-3.c fails to
link with e.g. binutils 2.30 (the linker in Trisquel 9), from before binutils
commit 4ec0995016801cc5d5cf13baf6e10163861e6852.  The error was "relocation
R_386_GOTOFF against STT_GNU_IFUNC symbol `foo' isn't supported".

Using a binutils 2.38.50 from May 2022, it doesn't fail to link, but it fails
at runtime.  The @GOTOFF relocation to the IFUNC appears to be handled
correctly only in PDEs.

I figured @GOTOFF for IFUNCs was an unreliable feature to use on x86, and
patched predicates.md:local_symbolic_operand to return !ix86_call_use_plt_p
(op) instead of true for SYMBOL_REF_LOCAL_P.  That got (pun not intended)
attr-ifunc-3.c to pass, but regressed the testcases named after this PR.

I started looking into how it was supposed to work, and how it managed to work
on x86_64, and understood the reasoning of forcing into existence and using the
PLT entry as the canonical address for the IFUNC.  That works for hidden
visibility, but I wondered, what if the symbol bound locally in a shared lib,
but was still visible to the main executable, i.e., protected visibility? 
Alas, even on x86_64, that resolves the IFUNC to different canonical addresses.

Specifically, compiling and linking pr83782-1.c s/hidden/protected/ into a
shared library, and then compiling and linking the following main program with
this library, the function calls succeed, but the pointer compare fails:

extern void foo (void);
extern void *bar(void);
int main() {
  void (*p)(void) = bar();
  p();
  foo();
  if (p != foo)
    __builtin_abort ();
}


ISTM the test has to be stricter than binding locally, it has to either be
known to be part of the main executable (-fPIE/-fpie) or known not to be
visible to other loadable modules.

As for x86, I don't see that it's prudent to use @GOTOFF for IFUNC even with
-fPIC: even if the PIE linker bug is fixed, regular PIC may be used in PIE, and
linkers since 2018 will silently misresolve the relocation.  WDYT?

  parent reply	other threads:[~2022-07-19  3:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-83782-4@http.gcc.gnu.org/bugzilla/>
2021-06-19 14:20 ` [Bug target/83782] [9/10/11/12 " hjl.tools at gmail dot com
2021-07-06  6:44 ` rguenth at gcc dot gnu.org
2021-12-03 13:13 ` cvs-commit at gcc dot gnu.org
2021-12-03 13:15 ` [Bug target/83782] [9/10/11 " hjl.tools at gmail dot com
2021-12-03 17:05 ` cvs-commit at gcc dot gnu.org
2022-05-27  9:38 ` [Bug target/83782] [10/11 " rguenth at gcc dot gnu.org
2022-06-28 10:34 ` jakub at gcc dot gnu.org
2022-07-19  3:42 ` aoliva at gcc dot gnu.org [this message]
2022-07-19 15:26 ` hjl.tools at gmail dot com
2022-07-20 20:39 ` aoliva at gcc dot gnu.org
2022-07-20 21:44 ` hjl.tools at gmail dot com
2022-08-01 18:29 ` cvs-commit at gcc dot gnu.org
2023-07-07 10:32 ` [Bug target/83782] [11 " rguenth at gcc dot gnu.org

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=bug-83782-4-1syZusBWau@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).