Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

[Josh Poimboeuf]

(spoiler alert: another bad gcc bug which is truncating functions...)

On Tue, Oct 11, 2016 at 10:05:41AM -0500, Josh Poimboeuf wrote:
> On Tue, Oct 11, 2016 at 03:30:20PM +0200, Arnd Bergmann wrote:
> > I've attached the three .config files here, but due to the size I
> > don't know if they make it to the list or your inbox. Let me
> > know if you get them, and if you are able to reproduce the problem.
> > 
> > The compiler version I used is gcc-6 (Ubuntu 6.2.0-3ubuntu11~16.04)
> > 6.2.0 20160901, and this is on top of linux-next plus a few other
> > patches.
> 
> Thanks, I got the configs, and I do see the warnings.  Will
> investigate...

1) 0x364C8CDB-config:
kernel/locking/rwsem.o: warning: objtool: down_write_killable()+0x16: call without frame pointer save/setup

This is a bug in kernel code in the ____down_write() macro.  It doesn't
ensure there's a stack frame before the call instruction.  Easy fix.


2) 0x3A1DA440-config:
drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f4: sibling call from callable instruction with changed frame pointer
drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer

These are false positive warnings, caused by the bane of objtool's
existence, gcc switch statement jump tables.  objtool needs to be made a
little smarter.


3) 0xFC244C03-config:
drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls through to next function fnic_handle_link_event()
drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of section

These look like another bad gcc bug which is truncating functions:

  0000000000000940 <snic_log_q_error>:
   940:   55                      push   %rbp
   941:   48 89 e5                mov    %rsp,%rbp
   944:   53                      push   %rbx
   945:   48 89 fb                mov    %rdi,%rbx
   948:   e8 00 00 00 00          callq  94d <snic_log_q_error+0xd>
                          949: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
   94d:   8b 83 58 02 00 00       mov    0x258(%rbx),%eax
   953:   85 c0                   test   %eax,%eax
   955:   75 08                   jne    95f <snic_log_q_error+0x1f>
   957:   e8 00 00 00 00          callq  95c <snic_log_q_error+0x1c>
                          958: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
   95c:   5b                      pop    %rbx
   95d:   5d                      pop    %rbp
   95e:   c3                      retq   
   95f:   e8 00 00 00 00          callq  964 <snic_log_q_error+0x24>
                          960: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
   964:   48 8b 83 10 1c 00 00    mov    0x1c10(%rbx),%rax
   96b:   48 8d 78 50             lea    0x50(%rax),%rdi
   96f:   e8 00 00 00 00          callq  974 <snic_log_q_error+0x34>
                          970: R_X86_64_PC32      ioread32-0x4
   974:   83 bb 58 02 00 00 01    cmpl   $0x1,0x258(%rbx)
   97b:   76 da                   jbe    957 <snic_log_q_error+0x17>
   97d:   e8 00 00 00 00          callq  982 <snic_log_q_error+0x42>
                          97e: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4

[end of file]

Notice how it just falls off the end of the function.  We had a similar
bug before:

  https://lkml.kernel.org/r/20160413033649.7r3msnmo3trtq47z@treble
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646

I'm not sure yet if this is the same gcc bug or a different one.  Maybe
it's related to the new GCC_PLUGIN_SANCOV?

-- 
Josh