Re: [PATCH] a more efficient BUG() macro

[Keith Owens]

On Sat, 17 Feb 2001 13:15:42 +0000 (GMT), 
Hugh Dickins <[e-mail]> 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.