Re: [PATCH] XBUG(comment) BUG enhancement

[Kai Germaschewski]

On Fri, 24 May 2002, Rusty Russell wrote:

> D: Introduces XBUG(comment) and XBUG_ON(comment) macros to PPC and
> D: i386.  XBUG prints out module (usually same as objfile without the
> D: .o) and the comment.
> D: 
> D: It also changes every BUG() in the headers files to XBUG(), so that
> D: the headers don't include absolute filenames, which allows the
> D: kernel compile to use ccache much better.

Just to mention an alternative (I think BUG() is actually designed to be 
easy to put in without bothering about writing some explanatory text), I 
think the main reason why this is introduced is ccache.

For people who don't know it, ccache(.samba.org) is a program which will 
cache the results from previous compiles and just copy the object file 
when command line and preprocessed input stayed the same. It immensely 
speeds up compiles when you're compiling the same tree twice with only 
minor changes, and it's particularly useful for people having multiple 
trees around, which only differ in patches they're working on. (As people 
who're using bk tend to do, for example)

Well, the last point is actually the issue this is all about. Since 
the BUG()'s in the headers will put the full path into the preprocessed 
file, ccache will have lots of cache misses, only due to this changed 
string.

There's basically two ways around this:
o Remove the __FILE__ in BUG() in headers, which Rusty's patch
  does
o Make sure that the __FILE__ does not contain absolute paths.

I have a patch which does the later, it replaces

	-I/home/kai/kernel/v2.5/linux-2.5.make-work/include
with
	-I../../include

(with the right number of '../')

With that patch you'd get
	
	"BUG in ../../include/linux/foo.h:234"

Now, I can't claim that's all that nice, but I think the previous full 
path was ugly, too (and we're talking about BUG() here, anyway).

I should mention that there's also another possibility, which actually 
looks nicer, but is a bit harder to implement:

Call gcc from $(TOPDIR), so it's always "-Iinclude", and you get

	"BUG in include/linux/foo.h:234".

That, BTW, has also the advantage of getting 
	
	"BUG in fs/hfs/inode.c:123"

instead of the current

	"BUG in inode.c:123"

Actually, I would think the last approach is the cleanest, so if there's 
interest in it, I can code it up.

--Kai