From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751544AbdISVj2 (ORCPT ); Tue, 19 Sep 2017 17:39:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40054 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751336AbdISVj1 (ORCPT ); Tue, 19 Sep 2017 17:39:27 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 69228C0587C5 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Tue, 19 Sep 2017 16:39:26 -0500 From: Josh Poimboeuf To: Arnd Bergmann Cc: Linux Kernel Mailing List Subject: Re: gcc-8 objtool warnings Message-ID: <20170919213926.jbphxuoyz3gt5gul@treble> References: <20170823124817.l3ersdabah75ampl@treble> <20170823160103.hlngl42raetj5ljq@treble> <20170824191920.lfnoavyxotq45ahn@treble> <20170919195226.jkxkyg5c534lf2sy@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 19 Sep 2017 21:39:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 19, 2017 at 10:43:31PM +0200, Arnd Bergmann wrote: > On Tue, Sep 19, 2017 at 9:52 PM, Josh Poimboeuf wrote: > > On Mon, Sep 11, 2017 at 04:34:52PM +0200, Arnd Bergmann wrote: > >> On Thu, Aug 24, 2017 at 9:19 PM, Josh Poimboeuf wrote: > >> 1. one configuration causing tons of warnings, on most compiler > >> versions (4.9 and newer), and even a couple of "unreachable > >> instruction warnings on gcc-4.3. > >> > >> arch/x86/mm/pageattr.o: warning: objtool: set_memory_x()+0x3a: call > >> without frame pointer save/setup > >> security/keys/keyring.o: warning: objtool: keyring_read()+0x70: leave > >> instruction with modified stack frame > >> arch/x86/events/intel/pt.o: warning: objtool: > >> pt_event_addr_filters_sync uses BP as a scratch register > > > > I downloaded the tarball, and I see configs/logs for the other problems, > > but not for this one. Did you forget to attach it, or did I miss it? > > I think what I ended up doing was to take the smallest files for that > configuration and packed them up, but the warnings I listed in the > mail don't match the ones for those files. However, it seems the > 0xEBFDB964_defconfig/log file got corrupted. > > I've uploaded a new copy to http://paste.ubuntu.com/25574959/ now. > > I've also experimented with other compiler versions > in the meantime and ran into similar problems on those version but did > not bother to take detailed notes about them since they are likely just > variants of the ones I already reported. If you can work around the > warnings I reported here, I can rerun with all compilers I have to > see if anything else shows up. Here's the fix for #1 and #2. I still need to work on the GCC 8 warnings. ----- From: Josh Poimboeuf Subject: [PATCH] objtool: Support unoptimized frame pointer setup Arnd Bergmann reported a bunch of warnings like: crypto/jitterentropy.o: warning: objtool: jent_fold_time()+0x3b: call without frame pointer save/setup crypto/jitterentropy.o: warning: objtool: jent_stuck()+0x1d: call without frame pointer save/setup crypto/jitterentropy.o: warning: objtool: jent_unbiased_bit()+0x15: call without frame pointer save/setup crypto/jitterentropy.o: warning: objtool: jent_read_entropy()+0x32: call without frame pointer save/setup crypto/jitterentropy.o: warning: objtool: jent_entropy_collector_free()+0x19: call without frame pointer save/setup and arch/x86/events/core.o: warning: objtool: collect_events uses BP as a scratch register arch/x86/events/core.o: warning: objtool: events_ht_sysfs_show()+0x22: call without frame pointer save/setup With certain rare configurations, GCC sometimes sets up the frame pointer with: lea (%rsp),%rbp instead of: mov %rsp,%rbp The instructions are equivalent, so treat the former like the latter. Reported-by: Arnd Bergmann Signed-off-by: Josh Poimboeuf --- tools/objtool/arch/x86/decode.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c index 0e8c8ec4fd4e..97a1fdb3db63 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -284,11 +284,16 @@ int arch_decode_instruction(struct elf *elf, struct section *sec, case 0x8d: if (sib == 0x24 && rex_w && !rex_b && !rex_x) { - /* lea disp(%rsp), reg */ *type = INSN_STACK; - op->src.type = OP_SRC_ADD; + if (!insn.displacement.value) { + /* lea (%rsp), reg */ + op->src.type = OP_SRC_REG; + } else { + /* lea disp(%rsp), reg */ + op->src.type = OP_SRC_ADD; + op->src.offset = insn.displacement.value; + } op->src.reg = CFI_SP; - op->src.offset = insn.displacement.value; op->dest.type = OP_DEST_REG; op->dest.reg = op_to_cfi_reg[modrm_reg][rex_r]; -- 2.13.5