From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jann Horn <jannh@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: objtool crashes on clang output (drivers/hwmon/pmbus/adm1275.o)
Date: Fri, 12 Jul 2019 08:57:55 -0500 [thread overview]
Message-ID: <20190712135755.7qa4wxw3bfmwn5rp@treble> (raw)
In-Reply-To: <CAK8P3a1_8kjzamn6_joBbZTO8NeGn0E3O+MZ+bcOQ0HkkRHXRQ@mail.gmail.com>
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 <leaf_copy_items_entirely+0x3a8>
...
23b1: e9 2a 01 00 00 jmpq 24e0 <leaf_copy_items_entirely+0x3d2>
...
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 <leaf_item_bottle>
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
next prev parent reply other threads:[~2019-07-12 13:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 12:40 objtool crashes on clang output (drivers/hwmon/pmbus/adm1275.o) Arnd Bergmann
2019-07-11 17:26 ` Josh Poimboeuf
2019-07-11 21:00 ` Arnd Bergmann
2019-07-11 21:04 ` Jann Horn
2019-07-11 21:29 ` Arnd Bergmann
2019-07-12 7:51 ` Arnd Bergmann
2019-07-12 13:57 ` Josh Poimboeuf [this message]
2019-07-12 14:19 ` Arnd Bergmann
2019-07-12 14:29 ` Josh Poimboeuf
2019-07-12 16:59 ` Nick Desaulniers
2019-07-12 20:40 ` Arnd Bergmann
2019-07-16 20:24 ` Nick Desaulniers
2019-07-16 22:05 ` Arnd Bergmann
2019-07-16 23:03 ` Josh Poimboeuf
2019-07-18 22:36 ` Nick Desaulniers
2019-07-18 23:20 ` Josh Poimboeuf
2019-07-11 23:20 ` 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=20190712135755.7qa4wxw3bfmwn5rp@treble \
--to=jpoimboe@redhat.com \
--cc=arnd@arndb.de \
--cc=clang-built-linux@googlegroups.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.