Re: "relocation to !ENDBR" objtool warnings

[Peter Zijlstra]

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?