Maybe other compilers dont grok __noinline or someone wants to make
them
inline anyway, who knows. :-)
do we have other compilers? I am offering a compromise and already
new
complaints. I think I should stick to just plain non-static
declarations. those are portable and don't fuckup ddb.....
Yes, we have other compilers -- we have one in the tree, which people
actually use, and our source code is supposed to be reasonably free
of GCC specific constructs (at least except very common ones) so that
it's not hard to bootstrap it on other compilers. FreeBSD currently
builds with LLVM and in the past, there have been efforts to build
NetBSD kernels with DEC C, icc, and lcc, with varying degrees of
success.
That's why we have macros like __predict_true() instead of directly
using the relevant GCC features. They can become NOPs with a compiler
that doesn't provide the feature. One here which gives "static
__noinline"
with GCC and "" with pcc would be shorter then typing out the whole
GCC syntax and certainly look cleaner!
As to inline or not with debug or diagnostic -- my personal taste is
that
if you really want to never have inlining in driver code that you
personally maintain, fine. But I think that in most parts of the
kernel
tree, we should not disable optimization unless DEBUG or DIAGNOSTIC.
As I think others have (obliquely) pointed out, addr2line or gdb can
get you better traceback information than ddb, given a core dump or
just the raw addresses from ddb's traceback. In the face of
aggressive
inlining by the compiler, there's really nothing that can get it
entirely
right -- but with a full symbol table, gdb/addr2line can do a _little_
better than ddb can.