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

From: Josh Poimboeuf
Date: Tue Oct 11 2016 - 12:02:45 EST


(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