BUG_ON()

先看代码吧:

[cpp]  view plain copy

1. <asm-generic/bug.h>  
2. #ifndef HAVE_ARCH_BUG  
3. #define BUG() do { /  
4.     printk("BUG: failure at %s:%d/%s()!/n", __FILE__, __LINE__, __func__); /  
5.     panic("BUG!"); /  
6. } while (0)  
7. #endif  
8. #ifndef HAVE_ARCH_BUG_ON  
9. #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)  
10. #endif  

对于blackfin来说有如下定义（现在没时间学习blackfin体系，还看不懂以后有时间在看了）：

[cpp]  view plain copy

1. <arch/blackfin/include/asm/bug.h>  
2. /* 
3.  * Copyright 2004-2009 Analog Devices Inc. 
4.  * 
5.  * Licensed under the GPL-2 or later. 
6.  */  
7. #ifndef _BLACKFIN_BUG_H  
8. #define _BLACKFIN_BUG_H  
9. #ifdef CONFIG_BUG  
10. #define BFIN_BUG_OPCODE 0xefcd  
11. #ifdef CONFIG_DEBUG_BUGVERBOSE  
12. #define _BUG_OR_WARN(flags)                     /  
13.     asm volatile(                           /  
14.         "1: .hword  %0/n"                   /  
15.         "   .section __bug_table,/"a/",@progbits/n"     /  
16.         "2: .long   1b/n"                   /  
17.         "   .long   %1/n"                   /  
18.         "   .short  %2/n"                   /  
19.         "   .short  %3/n"                   /  
20.         "   .org    2b + %4/n"              /  
21.         "   .previous"                  /  
22.         :                           /  
23.         : "i"(BFIN_BUG_OPCODE), "i"(__FILE__),          /  
24.           "i"(__LINE__), "i"(flags),                /  
25.           "i"(sizeof(struct bug_entry)))  
26. #else  
27. #define _BUG_OR_WARN(flags)                     /  
28.     asm volatile(                           /  
29.         "1: .hword  %0/n"                   /  
30.         "   .section __bug_table,/"a/",@progbits/n"     /  
31.         "2: .long   1b/n"                   /  
32.         "   .short  %1/n"                   /  
33.         "   .org    2b + %2/n"              /  
34.         "   .previous"                  /  
35.         :                           /  
36.         : "i"(BFIN_BUG_OPCODE), "i"(flags),         /  
37.           "i"(sizeof(struct bug_entry)))  
38. #endif /* CONFIG_DEBUG_BUGVERBOSE */  
39. #define BUG()                               /  
40.     do {                                /  
41.         _BUG_OR_WARN(0);                    /  
42.         for (;;);                       /  
43.     } while (0)  
44. #define WARN_ON(condition)                          /  
45.     ({                              /  
46.         int __ret_warn_on = !!(condition);          /  
47.         if (unlikely(__ret_warn_on))                /  
48.             _BUG_OR_WARN(BUGFLAG_WARNING);          /  
49.         unlikely(__ret_warn_on);                /  
50.     })  
51. #define HAVE_ARCH_BUG  
52. #define HAVE_ARCH_WARN_ON  
53. #endif  
54. #include <asm-generic/bug.h>  
55. #endif  

作用：一些内核调用可以用来方便标记bug，提供断言并输出信息。最常用的两个是BUG()和BUG_ON()。当被调用的时候，它们会引发oops，导致栈的回溯和错误信息的打印。为什么这些声明会导致 oops跟硬件的体系结构是相关的。大部分体系结构把BUG()和BUG_ON()定义成某种非法操作，这样自然会产生需要的oops。你可以把这些调用当作断言使用，想要断言某种情况不该发生 ：
if (bad_thing)
BUG();
或者使用更好的形式：
BUG_ON(bad_thing);

可以用panic()引发更严重的错误。调用panic()不但会打印错误消息而且还会挂起整个系统。显然，你只应该在极端恶劣的情况下使用它：
if (terrible_thing)
       panic("foo is %ld/n", foo);

 有些时候，你只是需要在终端上打印一下栈的回溯信息来帮助你测试。此时可以使用dump_stack()。它只在终端上打印寄存器上下文和函数的跟踪线索：
if (!debug_check) {
       printk(KERN_DEBUG "provide some information.../n");
       dump_stack();
}
from:http://www.lupaworld.com/bbs/thread-36983-1-8.html

A lots of places in linux kernel we encounter the macro BUG_ON.
BUG_ON macro first checks for the condition and if condition is true then it calls BUG which do a printk of msg and call panic which halts the system.(如果BUG_ON中的条件为真就调用BUG，它输出一些信息，然后调用panic函数挂起系统。)

The unlikely in BUG_ON macro is compiler directive which ask compiler to generate assembly such that the condition mentioned in unlikely isn't going to be met most-of-the time , which reduces jumps and speeds-up things, although if condition mentioned in unlikely met then there will be a long jump and speed will be effected, so must be used carefully. Same is withlikely as it is the opposite of unlikely .（据说likely一般是很少用的）

from: http://knol.google.com/k/vivek-bhadra/linux-debugging-bug-on/3c84lj4klzp0d/14#

 

这个unlikely()使我想到了之前看到过的一个宏__cold,原来这两个是同一个东西，__cold是4.3版本之后的gcc才支持的。

__cold的定义

[cpp]  view plain copy

1. <linux/compiler-gcc.h>  
2. #if __GNUC_MINOR__ >= 3  
3. /* Mark functions as cold. gcc will assume any path leading to a call 
4.    to them will be unlikely.  This means a lot of manual unlikely()s 
5.    are unnecessary now for any paths leading to the usual suspects 
6.    like BUG(), printk(), panic() etc. [but let's keep them for now for 
7.    older compilers] 
8.    Early snapshots of gcc 4.3 don't support this and we can't detect this 
9.    in the preprocessor, but we can live with this because they're unreleased. 
10.    Maketime probing would be overkill here. 
11.    gcc also has a __attribute__((__hot__)) to move hot functions into 
12.    a special section, but I don't see any sense in this right now in 
13.    the kernel context */  
14. #define __cold          __attribute__((__cold__))  

 

 

hot
The hot attribute is used to inform the compiler that a function is a hot spot of the compiled program. The function is optimized more aggressively and on many target it is placed into special subsection of the text section so all hot functions appears close together improving locality. 
When profile feedback is available, via -fprofile-use, hot functions are automatically detected and this attribute is ignored. 
The hot attribute is not implemented in GCC versions earlier than 4.3. 
cold
The cold attribute is used to inform the compiler that a function is unlikely executed. The function is optimized for size rather than speed and on many targets it is placed into special subsection of the text section so all cold functions appears close together improving code locality of non-cold parts of program. The paths leading to call of cold functions within code are marked as unlikely by the branch prediction mechanism. It is thus useful to mark functions used to handle unlikely conditions, such as perro r , as cold to improve optimization of hot functions that do call marked functions in rare occasions. 
When profile feedback is available, via -fprofile-use, hot functions are automatically detected and this attribute is ignored. 
The cold attribute is not implemented in GCC versions earlier than 4.3.

from: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Function-Attributes.html