Messages in this thread |  | | | From | Keith Owens <> | | Subject | Re: [PATCH] a more efficient BUG() macro | | Date | Sun, 18 Feb 2001 11:01:16 +1100 |
| |
On Sat, 17 Feb 2001 13:15:42 +0000 (GMT), Hugh Dickins <hugh@veritas.com> wrote: >On Sat, 17 Feb 2001, Paul Gortmaker wrote: >> Anyway this small patch makes sure there is only one "kernel BUG..." string, >> and dumps __FILE__ in favour of an address value since System.map data is >> needed to make full use of the BUG() dump anyways. The memory stats of two >> otherwise identical kernels: >substitute INLINE_BUG() in inline functions, but use your macro >(with 0x%p address) for it instead of mine. What do others think? >Keith, does the address format need adjusting to suit ksymoops? I would prefer to see
extern const char *kernel_bug; printk(kernel_bug, __C_FILE__, __C_LINE__)
init/main.c contains const char *kernel_bug = "kernel BUG at %s:%d!\n"; kernel_bug is also exported.
__C_FILE__ and __C_LINE__ refer to the .c or .s file that included the header, so you get the exact location of the failing code instead of the name and line number of a common header which is used all over the place. __C_FILE__ would be replaced with the minimum string required to uniquely identify the file, e.g. isdn_audio.c (unique at one level) or romfs/inode.c (unique at two levels).
Standard gcc will not do this. But as part of my makefile rewrite I am reading the pre-processed output as it is generated by cpp and before it is read by cc1, to extract data for module symbol versions. It is trivial for my code to look for __C_FILE__ and __C_LINE__ (cpp will have left them alone) and replace them with the relevant string and number.
Would people prefer the C/ASM filename in BUG() messages instead of the include header? If so I will add it to my todo list for the makefile rewrite. Of course you can still use __FILE__ and __LINE_ if you really want to report the error against the include file.
- 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/
|  |