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

[H.J. Lu]

On Thu, Feb 13, 2020 at 11:29 AM Fangrui Song <maskray@google.com> wrote:
>
> On 2020-02-13, H.J. Lu wrote:
> >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.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=25551

This is the patch I am checking in.

Thanks.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-Resolve-PLT32-reloc-aganst-local-symbol-to-secti.patch
Type: text/x-patch
Size: 5016 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20200213/f2b9b134/attachment.bin>