[Bug libc/30095] New: Inhibit early libcalls before ifunc support is ready

[Bug libc/30095] New: Inhibit early libcalls before ifunc support is ready

[cmuellner at linux dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30095

            Bug ID: 30095
           Summary: Inhibit early libcalls before ifunc support is ready
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: cmuellner at linux dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

When developing a first version of ifunc support for RISC-V, I encountered an
endless loop in the first few instructions of a statically linked RV64 binary.
When analyzing this issue, I observed that GCC has identified the loop in
_dl_aux_init() as memset-zero operation and replaced it with a libcall to
memset.

This turned out to be problematic because the ifunc support is not ready at
that time.

One solution is to set a function attribute to inhibit loop-to-libcall
transformations by the compiler ("-fno-tree-loop-distribute-patterns").
A corresponding patch has been sent as part of the RISC-V ifunc series:
  https://sourceware.org/pipermail/libc-alpha/2023-February/145350.html
 
https://patchwork.sourceware.org/project/glibc/patch/20230207001618.458947-2-christoph.muellner@vrull.eu/

The issue was triggered with GCC upstream/master and glibc upstream/master
cross-compiling glibc with "-O3" for RV64.

I believe this issue is not caused by a wrong implementation in the RISC-V
ifunc support, therefore, I decided the open this ticket (with the hope it can
get addressed independently of the ifunc series).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30095] Inhibit early libcalls before ifunc support is ready

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30095

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
This has been fixed by 5355f9ca7b10183ce06e8a18003ba30f43774858, where the idea
is that if ABI supports ifunc it should provide dl-symbol-redir-ifunc.h with
the default memset variant (maybe we should document it better on ABI port).

Using compiler builtins to avoid compiler issuing libcall is tricky (does it
work on all compilers? does it need to some optimization?) and error-prone
(should we inhibit per function or for whole module?).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30095] Inhibit early libcalls before ifunc support is ready

[cmuellner at linux dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30095

Christoph Müllner <cmuellner at linux dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Christoph Müllner <cmuellner at linux dot com> ---
Ok, understand.

The referenced change is from October 2022. The patch series was created before
that and just recently rebased. I ran into the issue after rebasing and created
the patch as a result of the analysis of the endless-loop.

I did look into the git history of the two C files to see if there was a recent
change, but I did not search for changed flags in Makefiles.

Thanks for clarifying this!

-- 
You are receiving this mail because:
You are on the CC list for the bug.