From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings
Date: Tue, 11 Oct 2016 10:51:46 -0500 [thread overview]
Message-ID: <20161011155146.icyl3zewdvmms2h2@treble> (raw)
In-Reply-To: <20161011150541.opini6gbolmnpzy5@treble>
(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
next prev parent reply other threads:[~2016-10-11 16:02 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 12:56 [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Arnd Bergmann
2016-10-10 20:23 ` Josh Poimboeuf
2016-10-11 8:08 ` Arnd Bergmann
2016-10-11 12:20 ` Josh Poimboeuf
2016-10-11 13:30 ` Arnd Bergmann
2016-10-11 15:05 ` Josh Poimboeuf
2016-10-11 15:51 ` Josh Poimboeuf [this message]
2016-10-11 20:38 ` Arnd Bergmann
2016-10-12 13:01 ` Josh Poimboeuf
2016-10-13 12:46 ` Another gcc corruption bug (was Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings) Josh Poimboeuf
2016-10-13 17:57 ` Denys Vlasenko
2016-10-13 20:15 ` Josh Poimboeuf
2017-03-01 9:34 ` [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Arnd Bergmann
2017-03-01 9:45 ` Arnd Bergmann
2017-03-01 14:40 ` Josh Poimboeuf
2017-03-01 15:27 ` Arnd Bergmann
2017-03-01 16:53 ` Josh Poimboeuf
2017-03-01 22:05 ` Arnd Bergmann
2017-03-01 22:42 ` Arnd Bergmann
2017-03-02 1:03 ` Josh Poimboeuf
2017-03-02 6:31 ` Ingo Molnar
2017-03-02 12:49 ` Josh Poimboeuf
2017-03-02 13:46 ` Ingo Molnar
2017-03-02 14:08 ` Josh Poimboeuf
2017-03-02 14:46 ` Ingo Molnar
2017-03-02 22:49 ` Arnd Bergmann
2017-03-02 23:05 ` Josh Poimboeuf
2017-03-03 8:58 ` Arnd Bergmann
2017-03-03 11:27 ` Arnd Bergmann
2017-03-01 14:31 ` Josh Poimboeuf
2017-03-01 15:21 ` Arnd Bergmann
2017-03-02 18:25 ` Josh Poimboeuf
2017-03-02 22:43 ` Arnd Bergmann
2017-03-02 22:57 ` [PATCH] objtool: fix another gcc jump table detection issue Josh Poimboeuf
2017-03-02 23:01 ` Arnd Bergmann
2016-10-11 1:53 ` [PATCH] objtool: support '-mtune=atom' stack frame setup instruction Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161011155146.icyl3zewdvmms2h2@treble \
--to=jpoimboe@redhat.com \
--cc=arnd@arndb.de \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).