lkml.org 
[lkml]   [2002]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] BUG preserve registers
Linus Torvalds wrote:
>
> On Sat, 9 Feb 2002, Andrew Morton wrote:
> >
> > This is due to BUG() calls in inline functions in headers. The biggest
> > culprit is dget(), in dcache.h. This causes the full path of the header file
> > to be expanded into each and every compilation unit which includes
> > dcache.h.
>
> Hmm. Which brings up another issue: can somebody come up with an idea of
> how to make the thing not use the whole pathname, but only the basename
> relative to the top-of-tree?

This is the cue for Keith to pop up and say "fixed in kbuild 2.5".

The preprocessor is simply pasting together its -I argument and the
string from the #include statement. There doesn't seem to be a way
of getting it to just emit "include/linux/dcache.h" or "drivers/char/serial.c".

__BASE_FILE__ seems to have been supported for a sufficiently long time. It
will just give us "dcache.h". I think that's OK. We don't get full path
info for the .c files either, and I'm not aware of that causing problems - if
there's a BUG() at inode.c:1234 we seem to be able to work out which inode.c
to look at.

__BASE_FILE__ is already used a bit in spinlock.h, so I think I'll
go with that. But I'll also take a look at all the inlined BUGs.


>
> Note that the correct thing to do may be to un-inline a lot of things.
> We've done that before, simply because it often improves performance.
>
> What ends up happening is that some function starts out really small, and
> then later on people add logic and debug code to it, and suddenly it's not
> really appropriate to inline any more.

I noticed :)


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

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.141 / U:3.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site