lkml.org 
[lkml]   [2009]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Definition of BUG on x86

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-02-19 17:19    [W:0.068 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site