[PATCH][RFC] getting rid of stupid loop in BUG()

[PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

	AFAICS, the patch below should do it for i386; instead of
using a dummy loop to tell gcc that this sucker never returns,
we do
static void __always_inline __noreturn __BUG(const char *file, int line);
containing the actual asm we want to insert and define BUG() as
__BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
experience with gcc __asm__ potential nastiness, so...

Comments, objections?

diff --git a/include/asm-i386/bug.h b/include/asm-i386/bug.h
index b0fd78c..294bc55 100644
--- a/include/asm-i386/bug.h
+++ b/include/asm-i386/bug.h
@@ -7,31 +7,27 @@
  * The offending file and line are encoded encoded in the __bug_table section.
  */
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
-#ifdef CONFIG_DEBUG_BUGVERBOSE
-#define BUG()								\
-	do {								\
-		asm volatile("1:\tud2\n"				\
-			     ".pushsection __bug_table,\"a\"\n"		\
-			     "2:\t.long 1b, %c0\n"			\
-			     "\t.word %c1, 0\n"				\
-			     "\t.org 2b+%c2\n"				\
-			     ".popsection"				\
-			     : : "i" (__FILE__), "i" (__LINE__),	\
-			     "i" (sizeof(struct bug_entry)));		\
-		for(;;) ;						\
-	} while(0)
+#define BUG() __BUG(__FILE__, __LINE__)
+
+#include <asm-generic/bug.h>
 
+#ifdef CONFIG_BUG
+static void __always_inline __noreturn __BUG(const char *file, int line)
+{
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+	asm volatile("1:\tud2\n"
+		     ".pushsection __bug_table,\"a\"\n"
+		     "2:\t.long 1b, %c0\n"
+		     "\t.word %c1, 0\n"
+		     "\t.org 2b+%c2\n"
+		     ".popsection"
+		     : : "i" (file), "i" (line),
+		     "i" (sizeof(struct bug_entry)));
 #else
-#define BUG()								\
-	do {								\
-		asm volatile("ud2");					\
-		for(;;) ;						\
-	} while(0)
+	asm volatile("ud2");
 #endif
+}
 #endif
-
-#include <asm-generic/bug.h>
 #endif

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Al Viro wrote:
> 	AFAICS, the patch below should do it for i386; instead of
> using a dummy loop to tell gcc that this sucker never returns,
> we do
> static void __always_inline __noreturn __BUG(const char *file, int line);
> containing the actual asm we want to insert and define BUG() as
> __BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
> experience with gcc __asm__ potential nastiness, so...
>
> Comments, objections?
>   

Does it work?  When I wrote the BUG code I tried this, but gcc kept
warning about "noreturn function returns".  I couldn't work out a way to
convince gcc that the asm is the end of the line.

I'm actually in favour of dropping the loop and the noreturn stuff
altogether.  It means that gcc thinks everything is live at the time of
the BUG, and the debugging info at the point of the ud2a is more useful.

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Jeremy Fitzhardinge wrote:
> Al Viro wrote:
>> 	AFAICS, the patch below should do it for i386; instead of
>> using a dummy loop to tell gcc that this sucker never returns,
>> we do
>> static void __always_inline __noreturn __BUG(const char *file, int line);
>> containing the actual asm we want to insert and define BUG() as
>> __BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
>> experience with gcc __asm__ potential nastiness, so...
>>
>> Comments, objections?
>>   
> 
> Does it work?  When I wrote the BUG code I tried this, but gcc kept
> warning about "noreturn function returns".  I couldn't work out a way to
> convince gcc that the asm is the end of the line.
> 
> I'm actually in favour of dropping the loop and the noreturn stuff
> altogether.  It means that gcc thinks everything is live at the time of
> the BUG, and the debugging info at the point of the ud2a is more useful.

How much code would that add to the kernel?

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

On Tue, Jul 24, 2007 at 09:56:21AM -0700, Jeremy Fitzhardinge wrote:
> Al Viro wrote:
> > 	AFAICS, the patch below should do it for i386; instead of
> > using a dummy loop to tell gcc that this sucker never returns,
> > we do
> > static void __always_inline __noreturn __BUG(const char *file, int line);
> > containing the actual asm we want to insert and define BUG() as
> > __BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
> > experience with gcc __asm__ potential nastiness, so...
> >
> > Comments, objections?
> >   
> 
> Does it work?  When I wrote the BUG code I tried this, but gcc kept
> warning about "noreturn function returns".  I couldn't work out a way to
> convince gcc that the asm is the end of the line.

Works here...
 
> I'm actually in favour of dropping the loop and the noreturn stuff
> altogether.  It means that gcc thinks everything is live at the time of
> the BUG, and the debugging info at the point of the ud2a is more useful.

It also means that gcc doesn't eliminate a bunch of codepaths.  It means
even more cretinous warnings about something being used uninitialized,
etc.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Al Viro wrote:
> On Tue, Jul 24, 2007 at 09:56:21AM -0700, Jeremy Fitzhardinge wrote:
>> Al Viro wrote:
>>> 	AFAICS, the patch below should do it for i386; instead of
>>> using a dummy loop to tell gcc that this sucker never returns,
>>> we do
>>> static void __always_inline __noreturn __BUG(const char *file, int line);
>>> containing the actual asm we want to insert and define BUG() as
>>> __BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
>>> experience with gcc __asm__ potential nastiness, so...
>>>
>>> Comments, objections?
>>>   
>> Does it work?  When I wrote the BUG code I tried this, but gcc kept
>> warning about "noreturn function returns".  I couldn't work out a way to
>> convince gcc that the asm is the end of the line.
> 
> Works here...

Could it be a gcc version difference?

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

H. Peter Anvin wrote:
> Could it be a gcc version difference?
>   

Likely.  Well, we can always try it and see how much crap turns up.  If
gcc keeps quiet about it, its certainly an improvement over the dummy loop.

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> Could it be a gcc version difference?
>>   
> 
> Likely.  Well, we can always try it and see how much crap turns up.  If
> gcc keeps quiet about it, its certainly an improvement over the dummy loop.
> 
>     J

You could do both, actually.  If gcc sees the end without it, the loop
will simply get dead-code eliminated.

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Al Viro wrote:
> Works here...
>   

Hm, doesn't here:

  CC      arch/i386/kernel/irq.o
/home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG':
include2/asm/bug.h:29: warning: 'noreturn' function does return

This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat
4.1.2-12)

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

On Tue, Jul 24, 2007 at 12:13:19PM -0700, Jeremy Fitzhardinge wrote:
> Al Viro wrote:
> > Works here...
> >   
> 
> Hm, doesn't here:
> 
>   CC      arch/i386/kernel/irq.o
> /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG':
> include2/asm/bug.h:29: warning: 'noreturn' function does return
> 
> This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat
> 4.1.2-12)

Interesting...  Looks like it's both version- and flags-dependent.
Oh, well...

BTW, alpha, frv, m68k and s390 have BUG() that is not recognized as
noreturn by gcc.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Al Viro wrote:
> On Tue, Jul 24, 2007 at 12:13:19PM -0700, Jeremy Fitzhardinge wrote:
>   
>> Al Viro wrote:
>>     
>>> Works here...
>>>   
>>>       
>> Hm, doesn't here:
>>
>>   CC      arch/i386/kernel/irq.o
>> /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG':
>> include2/asm/bug.h:29: warning: 'noreturn' function does return
>>
>> This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat
>> 4.1.2-12)
>>     
>
> Interesting...  Looks like it's both version- and flags-dependent.
> Oh, well...
>
> BTW, alpha, frv, m68k and s390 have BUG() that is not recognized as
> noreturn by gcc.
>   

Yes, it was something I added because I thought it would be useful. 
Traditionally, BUG has not affected gcc's control flow analysis.

The other option is trying to use __builtin_trap, which happens to
generate ud2a on i386.  But I don't think its necessarily guaranteed to
always do that, and I don't know if it does anything useful for other
architectures.

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Trent Piepho]

On Tue, 24 Jul 2007, Al Viro wrote:
> 	AFAICS, the patch below should do it for i386; instead of
> using a dummy loop to tell gcc that this sucker never returns,
> we do
> static void __always_inline __noreturn __BUG(const char *file, int line);
> containing the actual asm we want to insert and define BUG() as
> __BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
> experience with gcc __asm__ potential nastiness, so...

Sounds like it doesn't work:
http://gcc.gnu.org/ml/gcc/2007-02/msg00107.html

    [The] programmer won't get optimization he wants as after inlining this as
    after inlining this attribute information becomes completely lost.

    What about __builtin_trap?

    It results in int 6 that might not be applicable, but adding some control
    over it to i386 backend is definitly an option.

    Honza

It seems like if __BUG() is not inlined, you get the bogus noreturn does
return warning.  If it is inlined, then you lose the noreturn attribute and
un-reachable code paths aren't eliminated.  Adding __builtin_trap after the
asm might be an ok fix.  It will emit a spurious int 6, but that won't even be
reached since the asm doesn't return, and it probably be less extra code than
the loop.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Keith Owens]

Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote:
>Adding __builtin_trap after the
>asm might be an ok fix.  It will emit a spurious int 6, but that won't even be
>reached since the asm doesn't return, and it probably be less extra code than
>the loop.

int 6 is a two byte instruction, the loop generates jmp with an 8 bit
offset, also two bytes.  No change in code size.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Keith Owens wrote:
> Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote:
>> Adding __builtin_trap after the
>> asm might be an ok fix.  It will emit a spurious int 6, but that won't even be
>> reached since the asm doesn't return, and it probably be less extra code than
>> the loop.
> 
> int 6 is a two byte instruction, the loop generates jmp with an 8 bit
> offset, also two bytes.  No change in code size.
> 

INT 6 is #UD, so the __builtin_trap() replaces the ud2a as well as the loop.

How far back was __builtin_trap() supported?

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

H. Peter Anvin wrote:
> INT 6 is #UD, so the __builtin_trap() replaces the ud2a as well as the loop.
>   

__builtin_trap() emits an actual ud2a; the effect is an int 6, of course.

> How far back was __builtin_trap() supported?

I think its relatively recent, but it might be within our supported
compiler window.

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[David Miller]

From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Tue, 24 Jul 2007 23:24:55 -0700

> H. Peter Anvin wrote:
> > How far back was __builtin_trap() supported?
> 
> I think its relatively recent, but it might be within our supported
> compiler window.

I'm pretty sure it is.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Heiko Carstens]

On Tue, Jul 24, 2007 at 11:29:14PM -0700, David Miller wrote:
> From: Jeremy Fitzhardinge <jeremy@goop.org>
> Date: Tue, 24 Jul 2007 23:24:55 -0700
> 
> > H. Peter Anvin wrote:
> > > How far back was __builtin_trap() supported?
> > 
> > I think its relatively recent, but it might be within our supported
> > compiler window.
> 
> I'm pretty sure it is.

We had this in include/asm-s390/bug.h to avoid compile errors with gcc 3.2:

+#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
+	__builtin_trap();
+#else
+	asm volatile(".long 0");
+#endif

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Linus Torvalds]

On Tue, 24 Jul 2007, David Miller wrote:
>
> From: Jeremy Fitzhardinge <jeremy@goop.org>
> Date: Tue, 24 Jul 2007 23:24:55 -0700
> 
> > H. Peter Anvin wrote:
> > > How far back was __builtin_trap() supported?
> > 
> > I think its relatively recent, but it might be within our supported
> > compiler window.
> 
> I'm pretty sure it is.

.. and I'm pretty sure it's immaterial.

We don't just do the "ud2" instruction - we also do the file and line 
number information after it. Which means that __builtin_trap() is useless.

So we might as well keep the loop, since both are two-byte instructions 
that tell gcc that it will never continue.

		Linus

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Linus Torvalds wrote:
> .. and I'm pretty sure it's immaterial.
>
> We don't just do the "ud2" instruction - we also do the file and line 
> number information after it. Which means that __builtin_trap() is useless.
>   

No, not any more.  The file and line info is out of line, in a separate
section, indexed by the ud2a's eip.  The main problem with
__builtin_trap is that there's no certain way to get the actual ud2a eip
(ie, paste an asm label onto it).

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Jeremy Fitzhardinge wrote:
> Linus Torvalds wrote:
>> .. and I'm pretty sure it's immaterial.
>>
>> We don't just do the "ud2" instruction - we also do the file and line 
>> number information after it. Which means that __builtin_trap() is useless.
>>   
> 
> No, not any more.  The file and line info is out of line, in a separate
> section, indexed by the ud2a's eip.  The main problem with
> __builtin_trap is that there's no certain way to get the actual ud2a eip
> (ie, paste an asm label onto it).
> 

Same difference, then...

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Linus Torvalds]

On Wed, 25 Jul 2007, Jeremy Fitzhardinge wrote:
> 
> No, not any more.  The file and line info is out of line, in a separate
> section, indexed by the ud2a's eip.

That's irrelevant - the point is, we need to do the ud2 by hand, since we 
need to control the code generation in order to associate the ud2 with the 
proper file/linenr.

> The main problem with __builtin_trap is that there's no certain way to 
> get the actual ud2a eip (ie, paste an asm label onto it).

Right. Which is why we need to do it as an inline asm.

		Linus

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

On Wed, Jul 25, 2007 at 10:19:55AM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 25 Jul 2007, Jeremy Fitzhardinge wrote:
> > 
> > No, not any more.  The file and line info is out of line, in a separate
> > section, indexed by the ud2a's eip.
> 
> That's irrelevant - the point is, we need to do the ud2 by hand, since we 
> need to control the code generation in order to associate the ud2 with the 
> proper file/linenr.
> 
> > The main problem with __builtin_trap is that there's no certain way to 
> > get the actual ud2a eip (ie, paste an asm label onto it).
> 
> Right. Which is why we need to do it as an inline asm.

Who said that we need to populate that section from asm?  Define
a static variable in that section inside a block; identifier is
not a problem, obviously.

I'm not saying that it's not revolting, but it's not impossible.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Al Viro wrote:
> Who said that we need to populate that section from asm?  Define
> a static variable in that section inside a block; identifier is
> not a problem, obviously.
>
> I'm not saying that it's not revolting, but it's not impossible.
>   

I tried that, but there's still no way of getting a pointer to the ud2a
instruction in there.  gcc just generates garbage if you try to use use
the &&label syntax on a label which isn't (potentially) the target of a
goto (it just gets placed somewhere random).

But there's a bigger problem than that.  If the BUG is in code which can
be replicated (ie inlined or unrolled), then it would also require
replicating the static variable...

    J

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[David Miller]

From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Wed, 25 Jul 2007 10:36:49 -0700

> I tried that, but there's still no way of getting a pointer to the ud2a
> instruction in there.  gcc just generates garbage if you try to use use
> the &&label syntax on a label which isn't (potentially) the target of a
> goto (it just gets placed somewhere random).
> 
> But there's a bigger problem than that.  If the BUG is in code which can
> be replicated (ie inlined or unrolled), then it would also require
> replicating the static variable...

Another issue is that if you have a conditional trap instruction on
your cpu, and you try the __label__ trick, GCC no longer converts:

	BUG_ON(test)

into just a:

	set condition codes;
	conditional_trap;

sequence because the "stuff" inside the basic block is something
more than just the __builtin_trap().

The holy grail would be being able to get the perfect conditional
trap sequence, plus the annotations in a seperate section.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

David Miller wrote:
> 
> Another issue is that if you have a conditional trap instruction on
> your cpu, and you try the __label__ trick, GCC no longer converts:
> 
> 	BUG_ON(test)
> 
> into just a:
> 
> 	set condition codes;
> 	conditional_trap;
> 
> sequence because the "stuff" inside the basic block is something
> more than just the __builtin_trap().
> 
> The holy grail would be being able to get the perfect conditional
> trap sequence, plus the annotations in a seperate section.

I think that would require a custom gcc builtin, which we might be able
to ask the gcc folks for...

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[David Miller]

From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Wed, 25 Jul 2007 10:00:20 -0700

> No, not any more.  The file and line info is out of line, in a separate
> section, indexed by the ud2a's eip.  The main problem with
> __builtin_trap is that there's no certain way to get the actual ud2a eip
> (ie, paste an asm label onto it).

Yes, I tried very hard to accomplish this myself, it would be
wonderful if it could be made to work.  I tried tricks using __label__
in inline asm, everything.

It would be workable if condition codes could be passed into inline
asm statements somehow, or the address of the builtin_trap() could
be reliably obtained.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 24 Jul 2007, David Miller wrote:
> >
> > From: Jeremy Fitzhardinge <jeremy@goop.org>
> > Date: Tue, 24 Jul 2007 23:24:55 -0700
> > 
> > > H. Peter Anvin wrote:
> > > > How far back was __builtin_trap() supported?
> > > 
> > > I think its relatively recent, but it might be within our supported
> > > compiler window.
> > 
> > I'm pretty sure it is.
> 
> .. and I'm pretty sure it's immaterial.
> 
> We don't just do the "ud2" instruction - we also do the file and line 
> number information after it. Which means that __builtin_trap() is useless.
> 
> So we might as well keep the loop, since both are two-byte instructions 
> that tell gcc that it will never continue.

Umm...  Actually, we might be able to do something like
{
	l: __builtin_trap();
	static struct ... v __attribute__((section(...))) = { &&l, n, file };
}

except that it would need block-local labels and those are ugly (so's
&&<label>, while we are at it)...

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Al Viro wrote:
> On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
>>
>> On Tue, 24 Jul 2007, David Miller wrote:
>>> From: Jeremy Fitzhardinge <jeremy@goop.org>
>>> Date: Tue, 24 Jul 2007 23:24:55 -0700
>>>
>>>> H. Peter Anvin wrote:
>>>>> How far back was __builtin_trap() supported?
>>>> I think its relatively recent, but it might be within our supported
>>>> compiler window.
>>> I'm pretty sure it is.
>> .. and I'm pretty sure it's immaterial.
>>
>> We don't just do the "ud2" instruction - we also do the file and line 
>> number information after it. Which means that __builtin_trap() is useless.
>>
>> So we might as well keep the loop, since both are two-byte instructions 
>> that tell gcc that it will never continue.
> 
> Umm...  Actually, we might be able to do something like
> {
> 	l: __builtin_trap();
> 	static struct ... v __attribute__((section(...))) = { &&l, n, file };
> }
> 
> except that it would need block-local labels and those are ugly (so's
> &&<label>, while we are at it)...

I thought gcc was buggy when it came to passing &&labels to assembly.

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

On Wed, Jul 25, 2007 at 10:22:15AM -0700, H. Peter Anvin wrote:
> >> So we might as well keep the loop, since both are two-byte instructions 
> >> that tell gcc that it will never continue.
> > 
> > Umm...  Actually, we might be able to do something like
> > {
> > 	l: __builtin_trap();
> > 	static struct ... v __attribute__((section(...))) = { &&l, n, file };
> > }
> > 
> > except that it would need block-local labels and those are ugly (so's
> > &&<label>, while we are at it)...
> 
> I thought gcc was buggy when it came to passing &&labels to assembly.

Where do you see passing &&<label> to assembly?  More interesting question
is whether gcc believes it to be const...

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[David Howells]

Al Viro <viro@ftp.linux.org.uk> wrote:

> Where do you see passing &&<label> to assembly?  More interesting question
> is whether gcc believes it to be const...

Passing labels like that to assembly didn't used to work, which is a pity as
we could speed up things like get_user() if it could be made to.

David

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Al Viro wrote:
> On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
>   
>> On Tue, 24 Jul 2007, David Miller wrote:
>>     
>>> From: Jeremy Fitzhardinge <jeremy@goop.org>
>>> Date: Tue, 24 Jul 2007 23:24:55 -0700
>>>
>>>       
>>>> H. Peter Anvin wrote:
>>>>         
>>>>> How far back was __builtin_trap() supported?
>>>>>           
>>>> I think its relatively recent, but it might be within our supported
>>>> compiler window.
>>>>         
>>> I'm pretty sure it is.
>>>       
>> .. and I'm pretty sure it's immaterial.
>>
>> We don't just do the "ud2" instruction - we also do the file and line 
>> number information after it. Which means that __builtin_trap() is useless.
>>
>> So we might as well keep the loop, since both are two-byte instructions 
>> that tell gcc that it will never continue.
>>     
>
> Umm...  Actually, we might be able to do something like
> {
> 	l: __builtin_trap();
> 	static struct ... v __attribute__((section(...))) = { &&l, n, file };
> }
>
> except that it would need block-local labels and those are ugly (so's
> &&<label>, while we are at it)...
>   

I couldn't get it to work.  It would be nice, because it would more or
less eliminate the need for asm in setting up BUGs - particularly the
nasty asm setting up the structure.

But it just doesn't work.  The label &&l ends up pointing to is not
anywhere near the __builtin_trap instruction; I found it tended to point
to the start of the function prologue.

I reported it as a gcc bug, but they refused to hear of it.  Details at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305

    J
> -
> 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/
>   

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Chuck Ebbert]

On 07/25/2007 01:41 PM, Jeremy Fitzhardinge wrote:
> 
> I reported it as a gcc bug, but they refused to hear of it.  Details at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
> 

Wow.

I especially like "You should plan a better way. "

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[H. Peter Anvin]

Chuck Ebbert wrote:
> On 07/25/2007 01:41 PM, Jeremy Fitzhardinge wrote:
>> I reported it as a gcc bug, but they refused to hear of it.  Details at
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
>>
> 
> Wow.
> 
> I especially like "You should plan a better way. "

FWIW, at Transmeta we had a local extension to gcc called
"__builtin_not_reached()" which we used to tell gcc that an assembly
statement would terminate the control flow.

Another useful extension was a variant of __builtin_trap() which would
create a dummy ELF relocation for the trapping instruction with a target.

	-hpa

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[David Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 25 Jul 2007 13:37:00 -0700

> Another useful extension was a variant of __builtin_trap() which would
> create a dummy ELF relocation for the trapping instruction with a target.

That would be very useful.

Another idea that has been tossed around is to build with dwarf2
debugging, scan a pre-linked kernel image for conditional trap
instructions, and use the dwarf2 info to reconstruct the file and line
number information into the table of BUG entries.  Then perform the
final link and strip the dwarf2 debugging info out.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Linus Torvalds]

On Wed, 25 Jul 2007, Al Viro wrote:
> 
> Umm...  Actually, we might be able to do something like
> {
> 	l: __builtin_trap();
> 	static struct ... v __attribute__((section(...))) = { &&l, n, file };

No.

A C-level label is a pointer to a C-level construct.

The compiler may have reasons to put other instructions in between the 
label and the final end result of the __builtin_trap. The above may work 
for some trivial test-case, but in the end, the label and the __builtin 
are *not* atomic, and the compiler may well end up having register spills 
etc in there, or having CSE'd two traps, or any number of details meaning 
that the label doesn't point to the exact ud2 instruction.

			Linus

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro]

On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
> We don't just do the "ud2" instruction - we also do the file and line 
> number information after it. Which means that __builtin_trap() is useless.
> 
> So we might as well keep the loop, since both are two-byte instructions 
> that tell gcc that it will never continue.

Actually, the worse problem is that gcc will happily merge these guys.
And that's a killer.

Re: [PATCH][RFC] getting rid of stupid loop in BUG()

[Jeremy Fitzhardinge]

Al Viro wrote:
> On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
>   
>> We don't just do the "ud2" instruction - we also do the file and line 
>> number information after it. Which means that __builtin_trap() is useless.
>>
>> So we might as well keep the loop, since both are two-byte instructions 
>> that tell gcc that it will never continue.
>>     
>
> Actually, the worse problem is that gcc will happily merge these guys.
> And that's a killer.
>   

Merge __builtin_traps()?  Ugh.  But also, there's no real long-term
guarantee that it will keep generating ud2a.  The *only* mention of it
in the manual is a discussion that it will emit a call to abort() on
arches which don't otherwise support it.

    J