From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8C49C742BD for ; Fri, 12 Jul 2019 13:58:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B966B2080A for ; Fri, 12 Jul 2019 13:58:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727969AbfGLN57 (ORCPT ); Fri, 12 Jul 2019 09:57:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37004 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726254AbfGLN57 (ORCPT ); Fri, 12 Jul 2019 09:57:59 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 856F330833B5; Fri, 12 Jul 2019 13:57:58 +0000 (UTC) Received: from treble (ovpn-122-237.rdu2.redhat.com [10.10.122.237]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A803219C67; Fri, 12 Jul 2019 13:57:57 +0000 (UTC) Date: Fri, 12 Jul 2019 08:57:55 -0500 From: Josh Poimboeuf To: Arnd Bergmann Cc: Jann Horn , Peter Zijlstra , Linux Kernel Mailing List , clang-built-linux , Nick Desaulniers Subject: Re: objtool crashes on clang output (drivers/hwmon/pmbus/adm1275.o) Message-ID: <20190712135755.7qa4wxw3bfmwn5rp@treble> References: <20190711172621.a7ab7jorolicid3z@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Fri, 12 Jul 2019 13:57:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 12, 2019 at 09:51:35AM +0200, Arnd Bergmann wrote: > I no longer see any of the "can't find switch jump table" in last > nights randconfig > builds. I do see one other rare warning, see attached object file: > > fs/reiserfs/do_balan.o: warning: objtool: replace_key()+0x158: stack > state mismatch: cfa1=7+40 cfa2=7+56 > fs/reiserfs/do_balan.o: warning: objtool: balance_leaf()+0x2791: stack > state mismatch: cfa1=7+176 cfa2=7+192 > fs/reiserfs/ibalance.o: warning: objtool: balance_internal()+0xe8f: > stack state mismatch: cfa1=7+240 cfa2=7+248 > fs/reiserfs/ibalance.o: warning: objtool: > internal_move_pointers_items()+0x36f: stack state mismatch: cfa1=7+152 > cfa2=7+144 > fs/reiserfs/lbalance.o: warning: objtool: > leaf_cut_from_buffer()+0x58b: stack state mismatch: cfa1=7+128 > cfa2=7+112 > fs/reiserfs/lbalance.o: warning: objtool: > leaf_copy_boundary_item()+0x7a9: stack state mismatch: cfa1=7+104 > cfa2=7+96 > fs/reiserfs/lbalance.o: warning: objtool: > leaf_copy_items_entirely()+0x3d2: stack state mismatch: cfa1=7+120 > cfa2=7+128 > > I suspect this comes from the calls to the __reiserfs_panic() noreturn function, > but have not actually looked at the object file. Looking at one of the examples: 2346: 0f 85 6a 01 00 00 jne 24b6 ... 23b1: e9 2a 01 00 00 jmpq 24e0 ... 24b6: 31 ff xor %edi,%edi 24b8: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 24bb: R_X86_64_32S .rodata.str1.1 24bf: 48 c7 c2 00 00 00 00 mov $0x0,%rdx 24c2: R_X86_64_32S .rodata.str1.1+0x127b 24c6: 48 c7 c1 00 00 00 00 mov $0x0,%rcx 24c9: R_X86_64_32S .rodata.str1.1+0x1679 24cd: 41 b8 90 01 00 00 mov $0x190,%r8d 24d3: 49 c7 c1 00 00 00 00 mov $0x0,%r9 24d6: R_X86_64_32S .rodata.str1.1+0x127b 24da: b8 00 00 00 00 mov $0x0,%eax 24df: 55 push %rbp 24e0: 41 52 push %r10 24e2: e8 00 00 00 00 callq 24e7 24e3: R_X86_64_PC32 __reiserfs_panic-0x4 Objtool is correct this time: There *is* a stack state mismatch at 0x24e0. The stack size is different at 0x24e0, depending on whether it came from 0x2346 or from 0x23b1. In this case it's not a problem for code flow, because the basic block is a dead end. But it *is* a problem for unwinding. The location of the previous stack frame is nondeterministic. And that's extra important for calls to noreturn functions, because they often dump the stack before exiting. So it looks like a compiler bug to me. -- Josh