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

[Fangrui Song via binutils]

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.