This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
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.