From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A36AC3858428; Tue, 19 Jul 2022 03:42:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A36AC3858428 From: "aoliva at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 7.2.1 X-Bugzilla-Keywords: ABI X-Bugzilla-Severity: normal X-Bugzilla-Who: aoliva at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2022 03:42:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D83782 Alexandre Oliva changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aoliva at gcc dot gnu.org --- Comment #8 from Alexandre Oliva --- 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 fail= s to link with e.g. binutils 2.30 (the linker in Trisquel 9), from before binuti= ls 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 fai= ls 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 w= ork 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 li= b, but was still visible to the main executable, i.e., protected visibility?=20 Alas, even on x86_64, that resolves the IFUNC to different canonical addres= ses. Specifically, compiling and linking pr83782-1.c s/hidden/protected/ into a shared library, and then compiling and linking the following main program w= ith this library, the function calls succeed, but the pointer compare fails: extern void foo (void); extern void *bar(void); int main() { void (*p)(void) =3D bar(); p(); foo(); if (p !=3D 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?=