public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Ingo Molnar <mingo@elte.hu>
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 12:29:48 -0800	[thread overview]
Message-ID: <499DC13C.2000401@zytor.com> (raw)
In-Reply-To: <20090219185935.GA21820@elte.hu>

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?

	-hpa


  parent reply	other threads:[~2009-02-19 20:33 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 [this message]
2009-02-19 20:32     ` Ingo Molnar

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=499DC13C.2000401@zytor.com \
    --to=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox