On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote: > On Tue, Apr 28, 2020 at 03:38:55PM -0500, Josh Poimboeuf wrote: > > This one makes no sense to me. It looks like the assembler is inserting > > a jump as part of the alignment padding??? WTH. > > > > 0000000000000980 <common_spurious>: > > 980: 48 83 04 24 80 addq $0xffffffffffffff80,(%rsp) > > 985: e8 00 00 00 00 callq 98a <common_spurious+0xa> > > 986: R_X86_64_PLT32 interrupt_entry-0x4 > > 98a: e8 00 00 00 00 callq 98f <common_spurious+0xf> > > 98b: R_X86_64_PLT32 smp_spurious_interrupt-0x4 > > 98f: eb 7e jmp a0f <ret_from_intr> > > 991: eb 6d jmp a00 <common_interrupt> > > 993: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 99a: 00 00 00 00 > > 99e: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9a5: 00 00 00 00 > > 9a9: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9b0: 00 00 00 00 > > 9b4: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9bb: 00 00 00 00 > > 9bf: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9c6: 00 00 00 00 > > 9ca: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9d1: 00 00 00 00 > > 9d5: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9dc: 00 00 00 00 > > 9e0: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9e7: 00 00 00 00 > > 9eb: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) > > 9f2: 00 00 00 00 > > 9f6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) > > 9fd: 00 00 00 > > binutils.git/gas/configure/tc-i386.c:i386_generate_nops > > When there's too many NOPs (as here) it generates a JMP across the NOPS. > It makes some sort of sense, at some point executing NOPs is going to be > more expensive than a branch.. But shees..
Urgh. Even if I tell it specifically to pad with NOPs, it still does this "trick". I have no idea how to deal with this in objtool. -- Josh
