Messages in this thread | | | Date | Tue, 11 Oct 2016 10:51:46 -0500 | From | Josh Poimboeuf <> | Subject | Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings |
| |
(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
| |