All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Definition of BUG on x86
Date: Thu, 19 Feb 2009 17:16:49 +0100	[thread overview]
Message-ID: <20090219161649.GC9556@elte.hu> (raw)
In-Reply-To: <1235059883.15053.68.camel@nathan.suse.cz>


* Petr Tesarik <ptesarik@suse.cz> wrote:

> Ingo Molnar píše v Čt 19. 02. 2009 v 16:35 +0100:
> >[...]
> > * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > 
> > > Ingo Molnar wrote:
> > >> * Petr Tesarik <ptesarik@suse.cz> wrote:
> > >>
> > >>   
> > >>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:47 +0100:
> > >>>     
> > >>>> so GCC should be fixed and improved here, on several levels.
> > >>>>       
> > >>> Agree.
> > >>>
> > >>> But it takes some time, even if we start pushing right now. What's 
> > >>> your suggestion for the meantime? Keep the dummy jmp? And in case 
> > >>> anybody is concerned about saving every byte in the text section, 
> > >>> they can apply my dirty patch?
> > >>>
> > >>> Actually, this doesn't sound too bad.
> > >>>     
> > >>
> > >> yeah. Please forward the problem to the appropriate GCC list in any 
> > >> case.
> > >>
> > >>   
> > >
> > > I think the official answer for this case is to use __builtin_trap.  But:
> > >
> > > -- Built-in Function: void __builtin_trap (void)
> > >     This function causes the program to exit abnormally.  GCC
> > >     implements this function by using a target-dependent mechanism
> > >     (such as intentionally executing an illegal instruction) or by
> > >     calling `abort'.  ***The mechanism used may vary from release to
> > >     release so you should not rely on any particular implementation.***
> > >
> > > which in principle is hard for us to make use of.  In practice I think  
> > > it has always been ud2a on x86.
> > 
> > could we just do:
> > 
> > 	__builtin_trap();
> > 	for (;;);
> 
> I'm afraid that's not the point of the exercise. I'm trying to 
> trim BUG() to two bytes, while still making sure that the 
> Illegal Opcode exception is generated at the exact code point, 
> so we can track it down using the info in __bug_table. If 
> __builtin_trap() ever translates to anything else than ud2a in 
> the above code snippet, there will be no BUG reported. 
> Instead, the CPU that encountered the BUG() will burn CPU 
> cycles forever without any apparent reason.

Well, the important question is thatGCC will optimize out 
whatever comes after the __builtin_trap(), right? To guarantee 
an assert we can do something like:

 	__builtin_trap();
	panic("should never get here");

to guarantee a message. (But realistically GCC will at most 
generate a build error.)

	Ingo

  reply	other threads:[~2009-02-19 16:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1234975856.15053.16.camel@nathan.suse.cz>
     [not found] ` <499C4786.5010504@goop.org>
2009-02-19 11:40   ` Definition of BUG on x86 Petr Tesarik
2009-02-19 12:10     ` Ingo Molnar
2009-02-19 12:19       ` Petr Tesarik
2009-02-19 12:22         ` Ingo Molnar
2009-02-19 12:38           ` Petr Tesarik
2009-02-19 12:47             ` Ingo Molnar
2009-02-19 13:02               ` Petr Tesarik
2009-02-19 14:49                 ` Ingo Molnar
2009-02-19 15:32                   ` Jeremy Fitzhardinge
2009-02-19 15:35                     ` Ingo Molnar
2009-02-19 16:11                       ` Petr Tesarik
2009-02-19 16:16                         ` Ingo Molnar [this message]
2009-02-19 16:34                           ` Jeremy Fitzhardinge
2009-02-19 16:41                             ` Ingo Molnar
2009-02-19 20:07                             ` H. Peter Anvin
2009-02-19 20:26                               ` Ingo Molnar
2009-02-19 16:55                           ` Petr Tesarik
2009-02-19 16:32                       ` Jeremy Fitzhardinge
2009-02-19 18:38     ` H. Peter Anvin

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=20090219161649.GC9556@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.