From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Petr Tesarik <ptesarik@suse.cz>,
Jeremy Fitzhardinge <jeremy@goop.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: remove unneeded endless loop in BUG()
Date: Thu, 19 Feb 2009 21:32:21 +0100 [thread overview]
Message-ID: <20090219203221.GA10782@elte.hu> (raw)
In-Reply-To: <499DC13C.2000401@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> Ingo Molnar wrote:
>>
>> the problem is that the DO_BUG() will generate the u2d instruction into
>> a random place where GCC puts it. It certainly wont be in the place
>> where the __bug_table logic above expects it.
>>
>> The result will be cryptic crashes instead of a clean BUG message
>> assert.
>>
>
> I went and talked to H.J. Lu about this.
>
> He said __builtin_trap(); is functionally treated as an asm volatile,
> and that it is most likely impossible that gcc could do anything wrong
> here (he did specifically state that nothing can move across the asm
> volatile, and there are no data dependencies between the asm volatile
> and the __builtin_trap).
>
> He also agreed that the right way to do this is __builtin_not_reached(),
> and I promised to submit a feature request for this for a future version
> of gcc.
>
> Given that, I would suggest we back out the patch, and that when
> __builtin_not_reached(); is supported, we can simply do:
>
> #if __GNUC__ is recent enough
> # define not_reached() __builtin_not_reached()
> #else
> # define not_reached() for(;;)
> #endif
>
> OK?
Yeah, sounds good!
Ingo
prev parent reply other threads:[~2009-02-19 20:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 18:38 [PATCH] x86: remove unneeded endless loop in BUG() Petr Tesarik
2009-02-19 18:40 ` H. Peter Anvin
2009-02-19 18:59 ` Ingo Molnar
2009-02-19 19:53 ` H. Peter Anvin
2009-02-19 20:47 ` Jeremy Fitzhardinge
2009-02-19 20:48 ` H. Peter Anvin
2009-02-20 8:28 ` Petr Tesarik
2009-02-19 20:29 ` H. Peter Anvin
2009-02-19 20:32 ` Ingo Molnar [this message]
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=20090219203221.GA10782@elte.hu \
--to=mingo@elte.hu \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
/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.