On Tue, Apr 15, 2025 at 2:19 PM Ard Biesheuvel <a...@kernel.org> wrote:
>
> On Tue, 15 Apr 2025 at 09:48, Uros Bizjak <ubiz...@gmail.com> wrote:
> >
> > On Thu, Apr 10, 2025 at 2:27 PM Ard Biesheuvel <ardb+...@google.com> wrote:
> > >
> > > From: Ard Biesheuvel <a...@kernel.org>
> > >
> > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > > into function prologues when profiling is enabled, to avoid GOT-based
> > > indirect calls when a direct call would suffice.
> > >
> > > There are two problems with that change:
> > > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> > > whether or not a direct [PLT based] call is appropriate;
> > > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> > > does not emit the @PLT suffix, resulting in the wrong relocation to be
> > > used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> > >
> > > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > > account. This also ensures that -mnop-mcount works as expected when
> > > emitting the PLT based profiling calls.
> > >
> > > While at it, fix the 32-bit logic as well, and issue a PLT call unless
> > > PLTs are explicitly disabled.
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> > >
> > > Signed-off-by: Ard Biesheuvel <a...@kernel.org>
> > >
> > > gcc/ChangeLog:
> > >
> > > PR target/119386
> > > * config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
> > > where appropriate.
> > > (x86_function_profiler): Fall through to x86_print_call_or_nop()
> > > for PIC codegen when flag_plt is set.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR target/119386
> > > * gcc.target/i386/pr119386-1.c: New test.
> > > * gcc.target/i386/pr119386-2.c: New test.
> >
> > OK if there are no further comments in the next day or two.
> >
>
> Thanks
>
> > BTW: Do you have commit rights?
> >
>
> No I do not.
Both patches pushed to the mainline, will be backported to gcc-14.
Thanks,
Uros.
