Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Feb 13, 2020 at 10:05 AM Fangrui Song <maskray@google.com> wrote:
>
>
> On 2020-02-13, H.J. Lu wrote:
> >On Thu, Feb 13, 2020 at 9:29 AM Fangrui Song <maskray@google.com> wrote:
> >>
> >> On 2020-02-13, H.J. Lu wrote:
> >> >On Wed, Feb 12, 2020 at 11:25 PM Fangrui Song <maskray@google.com> wrote:
> >> >>
> >> >> See gas/testsuite/gas/i386/relax-5.s
> >> >> Currently gas incorrectly emits a .L symbol.
> >> >> Context: https://github.com/ClangBuiltLinux/linux/issues/811
>
> Sorry. I pasted a wrong link. It should be
> https://github.com/ClangBuiltLinux/linux/issues/872
>
> >> >> (begin story
> >> >>
> >> >> I taught clang to emit a call insn referencing a local symbol if the
> >> >> symbol is defined in the same translation unit. This can avoid unneeded
> >> >> PLT if the object file is linked with -shared.
> >> >
> >> >Why does a linker generate a PLT entry for PLT32 relocation against a local
> >> >symbol?  Does BFD linker have the same issue?
> >>
> >> The problem is not a linker, but objtool (used by the Linux kernel)'s
> >> unneeded constraint on st_type.
> >>
> >
> >I don't have any problem with PLT32 and objtool in the current Linux kernel.
> >Are you using very old Linux kernel?
>
> This is related to the latest change in linux-next.
>
>
>         .section        .init.text,"ax",@progbits
>         call    .Lprintk$local
>                                          # -- End function
>         .text
>         .globl  printk                  # -- Begin function printk
>         .type   printk,@function
> printk:                                 # @printk
> .Lprintk$local:
>   ret
>
> % as a.s -o a.o
> % readelf -Wrs a.o
>
> Relocation section '.rela.init.text' at offset 0x108 contains 1 entry:
>      Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
>      0000000000000001  0000000500000004 R_X86_64_PLT32     0000000000000000 .Lprintk$local - 4
> ...
>       5: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    1 .Lprintk$local
>
>
> `call   .Lprintk$local` is in a different section. It causes GNU as to
> emit an R_X86_64_PLT32 referencing a local symbol.
>
>  From https://sourceware.org/binutils/docs/as/Symbol-Names.html
>
> > Local symbols are defined and used within the assembler, but they are normally not saved in object files.
>
> R_X86_64_PC32 does not have the problem. I think this can be seen as a
> missed optimization.

Please open a binutils bug and I will take a look.

-- 
H.J.