public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [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).