* [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
@ 2020-02-13 7:25 Fangrui Song via binutils
2020-02-13 7:31 ` FÄng-ruì Sòng via binutils
2020-02-13 11:38 ` H.J. Lu
0 siblings, 2 replies; 9+ messages in thread
From: Fangrui Song via binutils @ 2020-02-13 7:25 UTC (permalink / raw)
To: binutils; +Cc: Nick Clifton, H.J. Lu
See gas/testsuite/gas/i386/relax-5.s
Currently gas incorrectly emits a .L symbol.
Context: https://github.com/ClangBuiltLinux/linux/issues/811
(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.
.globl foo
foo:
.Lfoo$local:
...
call .Lfoo$local
end story)
The test case x86-64-relax-5.d is almost correct, except the last line.
I cannot figure out how to make runtest accept the last line.
runtest is so rigid about whitespace and newlines.
<printk> is not significant to the test, but I have to include it,
otherwise runtest will complain.
This is how I run tests:
% cd ~/Dev/binutils-gdb/Release/gas
% runtest -v --tool gas --srcdir ../../gas/testsuite/ i386.exp
This command runs a number of unrelated test cases. Is it very difficult to
run an isolated test case? This will be super helpful when developing a
bug fix.
---
gas/config/tc-i386.c | 2 --
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/relax-5.s | 9 +++++++++
gas/testsuite/gas/i386/x86-64-relax-5.d | 17 +++++++++++++++++
4 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 gas/testsuite/gas/i386/relax-5.s
create mode 100644 gas/testsuite/gas/i386/x86-64-relax-5.d
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 680016ae45..a9d3a7de01 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -3398,7 +3398,6 @@ tc_i386_fix_adjustable (fixS *fixP ATTRIBUTE_UNUSED)
if (fixP->fx_r_type == BFD_RELOC_SIZE32
|| fixP->fx_r_type == BFD_RELOC_SIZE64
|| fixP->fx_r_type == BFD_RELOC_386_GOTOFF
- || fixP->fx_r_type == BFD_RELOC_386_PLT32
|| fixP->fx_r_type == BFD_RELOC_386_GOT32
|| fixP->fx_r_type == BFD_RELOC_386_GOT32X
|| fixP->fx_r_type == BFD_RELOC_386_TLS_GD
@@ -3411,7 +3410,6 @@ tc_i386_fix_adjustable (fixS *fixP ATTRIBUTE_UNUSED)
|| fixP->fx_r_type == BFD_RELOC_386_TLS_LE
|| fixP->fx_r_type == BFD_RELOC_386_TLS_GOTDESC
|| fixP->fx_r_type == BFD_RELOC_386_TLS_DESC_CALL
- || fixP->fx_r_type == BFD_RELOC_X86_64_PLT32
|| fixP->fx_r_type == BFD_RELOC_X86_64_GOT32
|| fixP->fx_r_type == BFD_RELOC_X86_64_GOTPCREL
|| fixP->fx_r_type == BFD_RELOC_X86_64_GOTPCRELX
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 2ca8a94132..60bd1113f4 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -1135,6 +1135,7 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_64_check]] t
run_dump_test "x86-64-relax-2"
run_dump_test "x86-64-relax-3"
+ run_dump_test "x86-64-relax-5"
run_dump_test "x86-64-jump"
run_dump_test "x86-64-branch-2"
diff --git a/gas/testsuite/gas/i386/relax-5.s b/gas/testsuite/gas/i386/relax-5.s
new file mode 100644
index 0000000000..f8bcfce0c5
--- /dev/null
+++ b/gas/testsuite/gas/i386/relax-5.s
@@ -0,0 +1,9 @@
+ .section .init.text,"ax",@progbits
+ call printk
+ call .Lprintk$local
+
+ .text
+ .global printk
+printk:
+.Lprintk$local:
+ ret
diff --git a/gas/testsuite/gas/i386/x86-64-relax-5.d b/gas/testsuite/gas/i386/x86-64-relax-5.d
new file mode 100644
index 0000000000..6ccd40af2b
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-relax-5.d
@@ -0,0 +1,17 @@
+#source: relax-5.s
+#objdump: -drw
+
+.*: +file format .*
+
+
+Disassembly of section .text:
+
+0+ <printk>:
+ 0: c3 retq
+
+Disassembly of section .init.text:
+
+0+ <.init.text>:
+ 0: e8 00 00 00 00 callq 5 <.init.text\+0x5> 1: R_X86_64_PLT32 printk-0x4
+ 5: e8 00 00 00 00 callq a <printk\+0xa> 6: R_X86_64_PLT32 .text-0x4
+#pass
--
2.25.0
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 7:25 [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section Fangrui Song via binutils
@ 2020-02-13 7:31 ` FÄng-ruì Sòng via binutils
2020-02-13 11:38 ` H.J. Lu
1 sibling, 0 replies; 9+ messages in thread
From: FÃÂng-ruì Sòng via binutils @ 2020-02-13 7:31 UTC (permalink / raw)
To: Binutils
> (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.
>
> .globl foo
> foo:
> .Lfoo$local:
> ...
> call .Lfoo$local
> end story)
clang traditionally only supported -fno-semantic-interposition. This
local symbol optimization can avoid unneeded PLT costs in a -shared
link, in case someone argues why clang is allowed to break "ELF
semantics".
(-fPIC -fsemantic-interposition will correctly emit call foo)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 7:25 [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section Fangrui Song via binutils
2020-02-13 7:31 ` FÄng-ruì Sòng via binutils
@ 2020-02-13 11:38 ` H.J. Lu
2020-02-13 17:29 ` Fangrui Song via binutils
1 sibling, 1 reply; 9+ messages in thread
From: H.J. Lu @ 2020-02-13 11:38 UTC (permalink / raw)
To: Fangrui Song; +Cc: Binutils, Nick Clifton
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
>
> (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?
> .globl foo
> foo:
> .Lfoo$local:
> ...
> call .Lfoo$local
> end story)
>
> The test case x86-64-relax-5.d is almost correct, except the last line.
> I cannot figure out how to make runtest accept the last line.
> runtest is so rigid about whitespace and newlines.
> <printk> is not significant to the test, but I have to include it,
> otherwise runtest will complain.
>
> This is how I run tests:
>
> % cd ~/Dev/binutils-gdb/Release/gas
> % runtest -v --tool gas --srcdir ../../gas/testsuite/ i386.exp
>
> This command runs a number of unrelated test cases. Is it very difficult to
> run an isolated test case? This will be super helpful when developing a
> bug fix.
>
It is hard to do since i386.exp doesn't use wild card.
--
H.J.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 11:38 ` H.J. Lu
@ 2020-02-13 17:29 ` Fangrui Song via binutils
2020-02-13 17:43 ` H.J. Lu
0 siblings, 1 reply; 9+ messages in thread
From: Fangrui Song via binutils @ 2020-02-13 17:29 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils, Nick Clifton
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
>>
>> (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.
GNU as emits an R_X86_64_PLT32 for `call .Lprintk$local`.
I think this is fine, and actually my preference for a call/jump instruction,
because PLT32 indicates that the address of the target function is not significant.
The linker should optimize it as if a PC32 if the symbol is
non-preemptible.
On the other hand, PC32 can mean the address is taken. Though it does
not matter when used on a local defined symbol (guaranteed
non-preemptible).
>> .globl foo
>> foo:
>> .Lfoo$local:
>> ...
>> call .Lfoo$local
>> end story)
>>
>> The test case x86-64-relax-5.d is almost correct, except the last line.
>> I cannot figure out how to make runtest accept the last line.
>> runtest is so rigid about whitespace and newlines.
>> <printk> is not significant to the test, but I have to include it,
>> otherwise runtest will complain.
>>
>> This is how I run tests:
>>
>> % cd ~/Dev/binutils-gdb/Release/gas
>> % runtest -v --tool gas --srcdir ../../gas/testsuite/ i386.exp
>>
>> This command runs a number of unrelated test cases. Is it very difficult to
>> run an isolated test case? This will be super helpful when developing a
>> bug fix.
>>
>
>It is hard to do since i386.exp doesn't use wild card.
Thanks for the explanation. This topic (dejagnu is very inconvenient) may deserve its own topic.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 17:29 ` Fangrui Song via binutils
@ 2020-02-13 17:43 ` H.J. Lu
2020-02-13 18:05 ` Fangrui Song via binutils
0 siblings, 1 reply; 9+ messages in thread
From: H.J. Lu @ 2020-02-13 17:43 UTC (permalink / raw)
To: Fangrui Song; +Cc: Binutils, Nick Clifton
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
> >>
> >> (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?
--
H.J.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 17:43 ` H.J. Lu
@ 2020-02-13 18:05 ` Fangrui Song via binutils
2020-02-13 18:20 ` H.J. Lu
0 siblings, 1 reply; 9+ messages in thread
From: Fangrui Song via binutils @ 2020-02-13 18:05 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils, Nick Clifton
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 18:05 ` Fangrui Song via binutils
@ 2020-02-13 18:20 ` H.J. Lu
2020-02-13 19:30 ` Fangrui Song via binutils
0 siblings, 1 reply; 9+ messages in thread
From: H.J. Lu @ 2020-02-13 18:20 UTC (permalink / raw)
To: Fangrui Song; +Cc: Binutils, Nick Clifton
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 18:20 ` H.J. Lu
@ 2020-02-13 19:30 ` Fangrui Song via binutils
2020-02-13 21:42 ` H.J. Lu
0 siblings, 1 reply; 9+ messages in thread
From: Fangrui Song via binutils @ 2020-02-13 19:30 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils, Nick Clifton
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section
2020-02-13 19:30 ` Fangrui Song via binutils
@ 2020-02-13 21:42 ` H.J. Lu
0 siblings, 0 replies; 9+ messages in thread
From: H.J. Lu @ 2020-02-13 21:42 UTC (permalink / raw)
To: Fangrui Song; +Cc: Binutils, Nick Clifton
[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]
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.
[-- Attachment #2: 0001-x86-Resolve-PLT32-reloc-aganst-local-symbol-to-secti.patch --]
[-- Type: text/x-patch, Size: 5016 bytes --]
From 07140a481b1837792a0e896a0b1357c2168c21e2 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Thu, 13 Feb 2020 13:26:22 -0800
Subject: [PATCH] x86: Resolve PLT32 reloc aganst local symbol to section
Since PLT entry isn't needed for branch to local symbol, we can resolve
R_386_PLT32/R_X86_64_PLT32 relocation aganst local symbol to section,
similar to R_386_PC32/R_X86_64_PC32.
2020-02-13 Fangrui Song <maskray@google.com>
H.J. Lu <hongjiu.lu@intel.com>
PR gas/25551
* config/tc-i386.c (tc_i386_fix_adjustable): Don't check
BFD_RELOC_386_PLT32 nor BFD_RELOC_X86_64_PLT32.
* testsuite/gas/i386/i386.exp: Run relax-5 and x86-64-relax-4.
* testsuite/gas/i386/relax-5.d: New file.
* testsuite/gas/i386/relax-5.s: Likewise.
* testsuite/gas/i386/x86-64-relax-4.d: Likewise.
* testsuite/gas/i386/x86-64-relax-4.s: Likewise.
---
gas/config/tc-i386.c | 2 --
gas/testsuite/gas/i386/i386.exp | 2 ++
gas/testsuite/gas/i386/relax-5.d | 15 +++++++++++++++
gas/testsuite/gas/i386/relax-5.s | 8 ++++++++
gas/testsuite/gas/i386/x86-64-relax-4.d | 17 +++++++++++++++++
gas/testsuite/gas/i386/x86-64-relax-4.s | 8 ++++++++
6 files changed, 50 insertions(+), 2 deletions(-)
create mode 100644 gas/testsuite/gas/i386/relax-5.d
create mode 100644 gas/testsuite/gas/i386/relax-5.s
create mode 100644 gas/testsuite/gas/i386/x86-64-relax-4.d
create mode 100644 gas/testsuite/gas/i386/x86-64-relax-4.s
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 6b923ccb81..8e422fd2dc 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -3398,7 +3398,6 @@ tc_i386_fix_adjustable (fixS *fixP ATTRIBUTE_UNUSED)
if (fixP->fx_r_type == BFD_RELOC_SIZE32
|| fixP->fx_r_type == BFD_RELOC_SIZE64
|| fixP->fx_r_type == BFD_RELOC_386_GOTOFF
- || fixP->fx_r_type == BFD_RELOC_386_PLT32
|| fixP->fx_r_type == BFD_RELOC_386_GOT32
|| fixP->fx_r_type == BFD_RELOC_386_GOT32X
|| fixP->fx_r_type == BFD_RELOC_386_TLS_GD
@@ -3411,7 +3410,6 @@ tc_i386_fix_adjustable (fixS *fixP ATTRIBUTE_UNUSED)
|| fixP->fx_r_type == BFD_RELOC_386_TLS_LE
|| fixP->fx_r_type == BFD_RELOC_386_TLS_GOTDESC
|| fixP->fx_r_type == BFD_RELOC_386_TLS_DESC_CALL
- || fixP->fx_r_type == BFD_RELOC_X86_64_PLT32
|| fixP->fx_r_type == BFD_RELOC_X86_64_GOT32
|| fixP->fx_r_type == BFD_RELOC_X86_64_GOTPCREL
|| fixP->fx_r_type == BFD_RELOC_X86_64_GOTPCRELX
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 2ca8a94132..8cace3dc9f 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -580,6 +580,7 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_32_check]]
run_dump_test "relax-3"
run_dump_test "relax-4"
+ run_dump_test "relax-5"
run_dump_test "got"
run_dump_test "got-no-relax"
@@ -1135,6 +1136,7 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_64_check]] t
run_dump_test "x86-64-relax-2"
run_dump_test "x86-64-relax-3"
+ run_dump_test "x86-64-relax-4"
run_dump_test "x86-64-jump"
run_dump_test "x86-64-branch-2"
diff --git a/gas/testsuite/gas/i386/relax-5.d b/gas/testsuite/gas/i386/relax-5.d
new file mode 100644
index 0000000000..bccfe681a0
--- /dev/null
+++ b/gas/testsuite/gas/i386/relax-5.d
@@ -0,0 +1,15 @@
+#objdump: -dwr
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <printk>:
+ +[a-f0-9]+: c3 ret
+
+Disassembly of section .init.text:
+
+0+ <foo>:
+ +[a-f0-9]+: e8 fb ff ff ff call 0 <foo> 1: R_386_PLT32 .text
+ +[a-f0-9]+: e8 fc ff ff ff call 6 <foo\+0x6> 6: R_386_PC32 .text
+#pass
diff --git a/gas/testsuite/gas/i386/relax-5.s b/gas/testsuite/gas/i386/relax-5.s
new file mode 100644
index 0000000000..35d5769f4a
--- /dev/null
+++ b/gas/testsuite/gas/i386/relax-5.s
@@ -0,0 +1,8 @@
+ .section .init.text,"ax",@progbits
+ .global foo
+foo:
+ call printk@PLT
+ call printk
+ .text
+printk:
+ ret
diff --git a/gas/testsuite/gas/i386/x86-64-relax-4.d b/gas/testsuite/gas/i386/x86-64-relax-4.d
new file mode 100644
index 0000000000..234e16534f
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-relax-4.d
@@ -0,0 +1,17 @@
+#objdump: -drw
+#notarget: *-*-solaris*
+
+.*: +file format .*
+
+
+Disassembly of section .text:
+
+0+ <printk>:
+ +[a-f0-9]+: c3 retq
+
+Disassembly of section .init.text:
+
+0+ <foo>:
+ +[a-f0-9]+: e8 00 00 00 00 callq 5 <foo\+0x5> 1: R_X86_64_PLT32 .text-0x4
+ +[a-f0-9]+: 48 8d 05 00 00 00 00 lea 0x0\(%rip\),%rax # c <foo\+0xc> 8: R_X86_64_PC32 .text-0x4
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-relax-4.s b/gas/testsuite/gas/i386/x86-64-relax-4.s
new file mode 100644
index 0000000000..683d3e2b9b
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-relax-4.s
@@ -0,0 +1,8 @@
+ .section .init.text,"ax",@progbits
+ .global foo
+foo:
+ call printk
+ lea printk(%rip), %rax
+ .text
+printk:
+ ret
--
2.24.1
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-02-13 21:42 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-13 7:25 [PATCH] x86-64: Resolve R_X86_64_PLT32 referencing a local symbol even if defined in another section Fangrui Song via binutils
2020-02-13 7:31 ` FÄng-ruì Sòng via binutils
2020-02-13 11:38 ` H.J. Lu
2020-02-13 17:29 ` Fangrui Song via binutils
2020-02-13 17:43 ` H.J. Lu
2020-02-13 18:05 ` Fangrui Song via binutils
2020-02-13 18:20 ` H.J. Lu
2020-02-13 19:30 ` Fangrui Song via binutils
2020-02-13 21:42 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).