Re: static functions are your friends (Was GPIO revisited)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Aug 09, 2009 at 07:42:10PM +0200, Marc Balmer wrote:
>>
>> 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.

Thor