* "relocation to !ENDBR" objtool warnings
@ 2024-12-17 8:54 Arnd Bergmann
2024-12-17 9:09 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2024-12-17 8:54 UTC (permalink / raw)
To: Josh Poimboeuf, Peter Zijlstra; +Cc: x86, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3250 bytes --]
Hi Josh and Peter,
I just sent three patches for the most common objtool warnings I get
with gcc-14 on linux-next.
There is one more that I can't figure out, maybe you have an idea
already. I've attached a .config that shows the problem in two files
when built with gcc-14.2.0.
Arnd
vmlinux.o: warning: objtool: x86_init_dev_msi_info+0x5b: relocation to !ENDBR: irq_chip_retrigger_hierarchy+0x0
vmlinux.o: warning: objtool: .export_symbol+0x3720: data relocation to !ENDBR: irq_chip_retrigger_hierarchy+0x0
vmlinux.o: warning: objtool: .export_symbol+0x252e8: data relocation to !ENDBR: stpcpy+0x0
vmlinux.o: warning: objtool: hv_pci_msi_controller+0x58: data relocation to !ENDBR: irq_chip_retrigger_hierarchy+0x0
vmlinux.o: warning: objtool: hpet_msi_controller+0x58: data relocation to !ENDBR: irq_chip_retrigger_hierarchy+0x0
vmlinux.o: warning: objtool: ioapic_ir_chip+0x58: data relocation to !ENDBR: irq_chip_retrigger_hierarchy+0x0
vmlinux.o: warning: objtool: ioapic_chip+0x58: data relocation to !ENDBR: irq_chip_retrigger_hierarchy+0x0
0000000000000210 <irq_chip_retrigger_hierarchy>:
210: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
217: 00 00 00 00
21b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
220: f3 0f 1e fa endbr64
224: 48 8b 7f 28 mov 0x28(%rdi),%rdi
228: 48 85 ff test %rdi,%rdi
22b: 74 17 je 244 <irq_chip_retrigger_hierarchy+0x34>
22d: 48 8b 47 18 mov 0x18(%rdi),%rax
231: 48 85 c0 test %rax,%rax
234: 74 ee je 224 <irq_chip_retrigger_hierarchy+0x14>
236: 48 8b 40 58 mov 0x58(%rax),%rax
23a: 48 85 c0 test %rax,%rax
23d: 74 e5 je 224 <irq_chip_retrigger_hierarchy+0x14>
23f: e9 00 00 00 00 jmp 244 <irq_chip_retrigger_hierarchy+0x34>
240: R_X86_64_PLT32 __x86_indirect_thunk_rax-0x4
244: 31 c0 xor %eax,%eax
246: 31 ff xor %edi,%edi
248: c3 ret
249: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
00000000000000f0 <stpcpy>:
f0: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
f7: 00 00 00 00
fb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
100: f3 0f 1e fa endbr64
104: 0f b6 06 movzbl (%rsi),%eax
107: 48 89 fa mov %rdi,%rdx
10a: 48 83 c6 01 add $0x1,%rsi
10e: 48 83 c7 01 add $0x1,%rdi
112: 88 47 ff mov %al,-0x1(%rdi)
115: 84 c0 test %al,%al
117: 75 eb jne 104 <stpcpy+0x14>
119: 48 89 d0 mov %rdx,%rax
11c: 31 d2 xor %edx,%edx
11e: 31 f6 xor %esi,%esi
120: 31 ff xor %edi,%edi
122: c3 ret
123: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
12a: 00 00 00 00
12e: 66 90 xchg %ax,%ax
[-- Attachment #2: 0x14CCB493-config.gz --]
[-- Type: application/gzip, Size: 36955 bytes --]
[-- Attachment #3: chip.o.gz --]
[-- Type: application/gzip, Size: 6509 bytes --]
[-- Attachment #4: string.o.gz --]
[-- Type: application/gzip, Size: 3445 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "relocation to !ENDBR" objtool warnings
2024-12-17 8:54 "relocation to !ENDBR" objtool warnings Arnd Bergmann
@ 2024-12-17 9:09 ` Arnd Bergmann
2024-12-17 10:37 ` Arnd Bergmann
2024-12-18 8:47 ` Josh Poimboeuf
0 siblings, 2 replies; 6+ messages in thread
From: Arnd Bergmann @ 2024-12-17 9:09 UTC (permalink / raw)
To: Josh Poimboeuf, Peter Zijlstra; +Cc: x86, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]
On Tue, Dec 17, 2024, at 09:54, Arnd Bergmann wrote:
>
> 00000000000000f0 <stpcpy>:
> f0: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
> f7: 00 00 00 00
> fb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 100: f3 0f 1e fa endbr64
I had one more look at the assembler file created by gcc and found
that this is a 16-byte nop:
.align 16
.globl stpcpy
.type stpcpy, @function
stpcpy:
.p2align 5
endbr64
.L30:
movzbl (%rsi), %eax # MEM[(const char *)src_8 + -1B], _1
movq %rdi, %rdx # dest, <retval>
addq $1, %rsi #, src
addq $1, %rdi #, dest
movb %al, -1(%rdi) # _1, MEM[(char *)dest_9 + -1B]
testb %al, %al # _1
jne .L30 #,
movq %rdx, %rax # <retval>,
xorl %edx, %edx #
xorl %esi, %esi #
xorl %edi, %edi #
ret
.size stpcpy, .-stpcpy
.align 16
No idea why it got inserted here, or why it only shows up in these
two functions. Having a nop before the endbr is a compiler bug, right?
Attaching the preprocessed file and .s file as well here.
This is the compiler command I used:
/home/arnd/cross/arm64/gcc-14.2.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc -Wp,-MMD,lib/.string.s.d -nostdinc -I/home/arnd/arm-soc/arch/x86/include -I./arch/x86/include/generated -I/home/arnd/arm-soc/include -I./include -I/home/arnd/arm-soc/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/arnd/arm-soc/include/uapi -I./include/generated/uapi -include /home/arnd/arm-soc/include/linux/compiler-version.h -include /home/arnd/arm-soc/include/linux/kconfig.h -include /home/arnd/arm-soc/include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=/home/arnd/arm-soc/= -Werror -DKCONFIG_SEED= -std=gnu2x -fshort-wchar -funsigned-char -fno-common -fno-PIE -fno-strict-aliasing -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=branch -fno-jump-tables -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -fno-jump-tables -fno-delete-null-pointer-checks -O2 -fno-allow-store-data-races -fstack-protector -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -fzero-call-used-regs=used-gpr -fno-inline-functions-called-once -fmin-function-alignment=16 -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack-check -fconserve-stack -Wall -Wundef -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Werror=strict-prototypes -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member -Wmissing-declarations -Wmissing-prototypes -Wframe-larger-than=2048 -Wunused-const-variable -Wno-dangling-pointer -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-overflow -Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wenum-conversion -Wextra -Wunused -Wformat-security -Wno-unused-but-set-variable -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation -Wno-override-init -Wno-missing-field-initializers -Wno-type-limits -Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare -Wno-unused-parameter -Werror -DKCONFIG_SEED= -ffreestanding -I/home/arnd/arm-soc/lib -Ilib -DKBUILD_MODFILE='"lib/string"' -DKBUILD_BASENAME='"string"' -DKBUILD_MODNAME='"string"' -D__KBUILD_MODNAME=kmod_string -fverbose-asm -S -o lib/string.s /home/arnd/arm-soc/lib/string.c
Arnd
[-- Attachment #2: string.s.gz --]
[-- Type: application/gzip, Size: 10419 bytes --]
[-- Attachment #3: string.i.gz --]
[-- Type: application/gzip, Size: 22429 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "relocation to !ENDBR" objtool warnings
2024-12-17 9:09 ` Arnd Bergmann
@ 2024-12-17 10:37 ` Arnd Bergmann
2024-12-18 8:47 ` Josh Poimboeuf
1 sibling, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2024-12-17 10:37 UTC (permalink / raw)
To: Josh Poimboeuf, Peter Zijlstra; +Cc: x86, linux-kernel
On Tue, Dec 17, 2024, at 10:09, Arnd Bergmann wrote:
> On Tue, Dec 17, 2024, at 09:54, Arnd Bergmann wrote:
>>
>> 00000000000000f0 <stpcpy>:
>> f0: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
>> f7: 00 00 00 00
>> fb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
>> 100: f3 0f 1e fa endbr64
>
>
> I had one more look at the assembler file created by gcc and found
> that this is a 16-byte nop:
>
> .align 16
> .globl stpcpy
> .type stpcpy, @function
> stpcpy:
> .p2align 5
> endbr64
...
>
> No idea why it got inserted here, or why it only shows up in these
> two functions. Having a nop before the endbr is a compiler bug, right?
I confirmed that this is only a problem on gcc-14.2, both gcc-14.1
and gcc trunk (15.0 I assume) are fine according to the compiler
explorer: https://godbolt.org/z/9xf7Ph8GT
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "relocation to !ENDBR" objtool warnings
2024-12-17 9:09 ` Arnd Bergmann
2024-12-17 10:37 ` Arnd Bergmann
@ 2024-12-18 8:47 ` Josh Poimboeuf
2024-12-18 10:08 ` Peter Zijlstra
1 sibling, 1 reply; 6+ messages in thread
From: Josh Poimboeuf @ 2024-12-18 8:47 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Peter Zijlstra, x86, linux-kernel
On Tue, Dec 17, 2024 at 10:09:56AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 17, 2024, at 09:54, Arnd Bergmann wrote:
> >
> > 00000000000000f0 <stpcpy>:
> > f0: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
> > f7: 00 00 00 00
> > fb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > 100: f3 0f 1e fa endbr64
>
>
> I had one more look at the assembler file created by gcc and found
> that this is a 16-byte nop:
>
> .align 16
> .globl stpcpy
> .type stpcpy, @function
> stpcpy:
> .p2align 5
> endbr64
> .L30:
> movzbl (%rsi), %eax # MEM[(const char *)src_8 + -1B], _1
> movq %rdi, %rdx # dest, <retval>
> addq $1, %rsi #, src
> addq $1, %rdi #, dest
> movb %al, -1(%rdi) # _1, MEM[(char *)dest_9 + -1B]
> testb %al, %al # _1
> jne .L30 #,
> movq %rdx, %rax # <retval>,
> xorl %edx, %edx #
> xorl %esi, %esi #
> xorl %edi, %edi #
> ret
> .size stpcpy, .-stpcpy
> .align 16
>
> No idea why it got inserted here, or why it only shows up in these
> two functions. Having a nop before the endbr is a compiler bug, right?
Yeah, looks like a bug to me.
--
Josh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "relocation to !ENDBR" objtool warnings
2024-12-18 8:47 ` Josh Poimboeuf
@ 2024-12-18 10:08 ` Peter Zijlstra
2024-12-18 10:38 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2024-12-18 10:08 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Arnd Bergmann, x86, linux-kernel
On Wed, Dec 18, 2024 at 12:47:29AM -0800, Josh Poimboeuf wrote:
> On Tue, Dec 17, 2024 at 10:09:56AM +0100, Arnd Bergmann wrote:
> > On Tue, Dec 17, 2024, at 09:54, Arnd Bergmann wrote:
> > >
> > > 00000000000000f0 <stpcpy>:
> > > f0: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
> > > f7: 00 00 00 00
> > > fb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > > 100: f3 0f 1e fa endbr64
> >
> >
> > I had one more look at the assembler file created by gcc and found
> > that this is a 16-byte nop:
> >
> > .align 16
> > .globl stpcpy
> > .type stpcpy, @function
> > stpcpy:
> > .p2align 5
> > endbr64
> > .L30:
> > movzbl (%rsi), %eax # MEM[(const char *)src_8 + -1B], _1
> > movq %rdi, %rdx # dest, <retval>
> > addq $1, %rsi #, src
> > addq $1, %rdi #, dest
> > movb %al, -1(%rdi) # _1, MEM[(char *)dest_9 + -1B]
> > testb %al, %al # _1
> > jne .L30 #,
> > movq %rdx, %rax # <retval>,
> > xorl %edx, %edx #
> > xorl %esi, %esi #
> > xorl %edi, %edi #
> > ret
> > .size stpcpy, .-stpcpy
> > .align 16
> >
> > No idea why it got inserted here, or why it only shows up in these
> > two functions. Having a nop before the endbr is a compiler bug, right?
>
> Yeah, looks like a bug to me.
Did you find https://gcc.gnu.org/PR116174 again?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "relocation to !ENDBR" objtool warnings
2024-12-18 10:08 ` Peter Zijlstra
@ 2024-12-18 10:38 ` Arnd Bergmann
0 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2024-12-18 10:38 UTC (permalink / raw)
To: Peter Zijlstra, Josh Poimboeuf; +Cc: x86, linux-kernel
On Wed, Dec 18, 2024, at 11:08, Peter Zijlstra wrote:
> On Wed, Dec 18, 2024 at 12:47:29AM -0800, Josh Poimboeuf wrote:
>> On Tue, Dec 17, 2024 at 10:09:56AM +0100, Arnd Bergmann wrote:
>> >
>> > No idea why it got inserted here, or why it only shows up in these
>> > two functions. Having a nop before the endbr is a compiler bug, right?
>>
>> Yeah, looks like a bug to me.
>
> Did you find https://gcc.gnu.org/PR116174 again?
Yes, I see my problem now: it turns out that the fixed version
was installed, but I was using the release version in my
randconfig tests, not the one that had the patch.
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-12-18 10:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-12-17 8:54 "relocation to !ENDBR" objtool warnings Arnd Bergmann
2024-12-17 9:09 ` Arnd Bergmann
2024-12-17 10:37 ` Arnd Bergmann
2024-12-18 8:47 ` Josh Poimboeuf
2024-12-18 10:08 ` Peter Zijlstra
2024-12-18 10:38 ` Arnd Bergmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®