From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool: improve detection of BUG() and other dead ends
Date: Tue, 21 Feb 2017 22:43:26 +0100 [thread overview]
Message-ID: <20170221214326.GL6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <41a6d33971462ebd944a1c60ad4bf5be86c17b77.1487712920.git.jpoimboe@redhat.com>
On Tue, Feb 21, 2017 at 03:35:32PM -0600, Josh Poimboeuf wrote:
> The BUG() macro's use of __builtin_unreachable() via the unreachable()
> macro tells gcc that the instruction is a dead end, and that it's safe
> to assume the current code path will not execute past the previous
> instruction.
>
> On x86, the BUG() macro is implemented with the 'ud2' instruction. When
> objtool's branch analysis sees that instruction, it knows the current
> code path has come to a dead end.
>
> Peter Zijlstra has been working on a patch to change the WARN macros to
> use 'ud2'. That patch will break objtool's assumption that 'ud2' is
> always a dead end.
>
> Generally it's best for objtool to avoid making those kinds of
> assumptions anyway. The more ignorant it is of kernel code internals,
> the better.
>
> So create a more generic way for objtool to detect dead ends by adding
> an annotation to the unreachable() macro. The annotation stores a
> pointer to the end of the unreachable code path in an '__unreachable'
> section. Objtool can read that section to find the dead ends.
>
Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
next prev parent reply other threads:[~2017-02-21 21:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 21:35 [PATCH] objtool: improve detection of BUG() and other dead ends Josh Poimboeuf
2017-02-21 21:43 ` Peter Zijlstra [this message]
2017-02-24 9:18 ` [tip:core/urgent] objtool: Improve " tip-bot for 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=20170221214326.GL6515@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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 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.