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?
next prev 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: linkBe 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).