[Bug target/83782] [9/10/11/12 Regression] Inconsistent address for hidden ifunc in a shared library

[Bug target/83782] [9/10/11/12 Regression] Inconsistent address for hidden ifunc in a shared library

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
             Blocks|                            |51469
            Summary|Inconsistent address for    |[9/10/11/12 Regression]
                   |hidden ifunc in a shared    |Inconsistent address for
                   |library                     |hidden ifunc in a shared
                   |                            |library
     Ever confirmed|0                           |1
         Resolution|DUPLICATE                   |---
   Last reconfirmed|                            |2021-06-19
                 CC|hjl at gcc dot gnu.org             |hjl.tools at gmail dot com,
                   |                            |meissner at linux dot ibm.com

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
This introduced in GCC 4.7 by

commit 15ce64af29141facd203687d000e21fe6f877234
Author: Michael Meissner <meissner@the-meissners.org>
Date:   Fri Dec 9 17:10:27 2011 +0000

    Fix PR51469 (attr-ifunc fails on ppc); Make #pragma GCC target ("...")
change macros on PPC

    From-SVN: r182169

The issue is PowerPC specific.  But the fix impacts all targets.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51469
[Bug 51469] attr-ifunc-* tests fail on PowerPC if
--enable-gnu-indirect-function is used

[Bug target/83782] [9/10/11/12 Regression] Inconsistent address for hidden ifunc in a shared library

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.5

[Bug target/83782] [9/10/11/12 Regression] Inconsistent address for hidden ifunc in a shared library

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:f7854b908977adce4ff669c4e0332ef868568b7c

commit r12-5771-gf7854b908977adce4ff669c4e0332ef868568b7c
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sat Jun 19 08:16:45 2021 -0700

    Add TARGET_IFUNC_REF_LOCAL_OK

    1. On some targets, like PowerPC, reference to ifunc function resolver
    must be non-local so that compiler will properly emit PLT call.  Add
    TARGET_IFUNC_REF_LOCAL_OK to allow binding indirect function resolver
    locally for targets which don't require special PLT call sequence.
    2. Add ix86_call_use_plt_p to call local ifunc function resolvers via
    PLT.

    gcc/

            PR target/51469
            PR target/83782
            * target.def (ifunc_ref_local_ok): Add a target hook.
            * varasm.c (default_binds_local_p_3): Force indirect function
            resolver non-local only if targetm.ifunc_ref_local_ok returns
            false.
            * config/i386/i386-expand.c (ix86_expand_call): Call
            ix86_call_use_plt_p to check if PLT should be used.
            * config/i386/i386-protos.h (ix86_call_use_plt_p): New.
            * config/i386/i386.c (output_pic_addr_const): Call
            ix86_call_use_plt_p to check if "@PLT" is needed.
            (ix86_call_use_plt_p): New.
            (TARGET_IFUNC_REF_LOCAL_OK): New.
            * doc/tm.texi.in: Add TARGET_IFUNC_REF_LOCAL_OK.
            * doc/tm.texi: Regenerated.

    gcc/testsuite/

            PR target/51469
            PR target/83782
            * gcc.target/i386/pr83782-1.c: New test.
            * gcc.target/i386/pr83782-2.c: Likewise.

[Bug target/83782] [9/10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW
            Summary|[9/10/11/12 Regression]     |[9/10/11 Regression]
                   |Inconsistent address for    |Inconsistent address for
                   |hidden ifunc in a shared    |hidden ifunc in a shared
                   |library                     |library

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for GCC 12 so far.

[Bug target/83782] [9/10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:37fbf9175b22dea2e5eca4393edd0c47e3008994

commit r12-5775-g37fbf9175b22dea2e5eca4393edd0c47e3008994
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Dec 3 09:00:54 2021 -0800

    x86: Scan leal in PR target/83782 tests for x32

    Update PR target/83782 tests to scan leal for x32 to fix:

    FAIL: gcc.target/i386/pr83782-1.c scan-assembler leaq[ \\t]foo\\(%rip\\),[
\\t]%rax
    FAIL: gcc.target/i386/pr83782-2.c scan-assembler leaq[ \\t]foo\\(%rip\\),[
\\t]%rax

            PR target/83782
            * gcc.target/i386/pr83782-1.c: Also scan leal x32.
            * gcc.target/i386/pr83782-2.c: Likewise.

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[aoliva at gcc dot gnu.org]

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?

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Alexandre Oliva from comment #8)
> 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.
> 

-fpie -pie -O0 -m32 and -fpie -pie -O2 -m32 work for me with
gcc.dg/attr-ifunc-3.c
on Fedora 36 and binutils 20220703.  Please provide the broken attr-ifunc-3.o
and
the command line used to compile it.

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
sorry, I typoed the failing test.  it's in g++.dg/ext, and it has a .C
extesion.  how unfortunate that there was another test matching the lower-case
name I typoed.

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
The problem is that calling an IFUNC class member function via a member
function
pointer needs PLT in 32-bit mode since the IFUNC function pointer points to its
PLT entry.  But we don't want to require PLT for calling via a function
pointer.

[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:80928920147a109a7f8735bffc55a72cbe8db185

commit r13-1919-g80928920147a109a7f8735bffc55a72cbe8db185
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Jul 20 16:57:32 2022 -0700

    x86: Add ix86_ifunc_ref_local_ok

    We can't always use the PLT entry as the function address for local IFUNC
    functions.  When the PIC register is needed for PLT call, indirect call
    via the PLT entry will fail since the PIC register may not be set up
    properly for indirect call.  Add ix86_ifunc_ref_local_ok to return false
    when the PLT entry can't be used as local IFUNC function pointers.

    gcc/

            PR target/83782
            * config/i386/i386.cc (ix86_ifunc_ref_local_ok): New.
            (TARGET_IFUNC_REF_LOCAL_OK): Use it.

    gcc/testsuite/

            PR target/83782
            * gcc.target/i386/pr83782-1.c: Require non-ia32.
            * gcc.target/i386/pr83782-2.c: Likewise.
            * gcc.target/i386/pr83782-3.c: New test.

[Bug target/83782] [11 Regression] Inconsistent address for hidden ifunc in a shared library

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.