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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox