[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: static functions are your friends (Was GPIO revisited)
On Mon, Aug 10, 2009 at 11:40:16AM +0200, Marc Balmer wrote:
> >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
> >with GCC and "" with pcc would be shorter then typing out the whole
> >GCC syntax and certainly look cleaner!
> Hmm, do we have example code somewehre in the tree?
Yes, in sys/sys/cdefs.h. Look at __predict_true/__predict_false
for example, or __RENAME
> >As to inline or not with debug or diagnostic -- my personal taste is
> >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
> >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
> >inlining by the compiler, there's really nothing that can get it
> >right -- but with a full symbol table, gdb/addr2line can do a _little_
> >better than ddb can.
> Thanks for the feedback. Actually I just saw that /usr/include/sys/
> cdefs has the following in it:
> #ifndef __GNUC__
> #define __const /* delete pseudo-ANSI C
> keywords */
> #define __inline
> #define __signed
> #define __volatile
> #endif /* !__GNUC__ */
> So I assume that as long as I include this file, the use of __inline
> should be save, right?
__inline is safe; but I'm not sure if we prefer to use __inline or inline
these days. It seems new code uses inline and not __inline.
For your purpose I think you want a __noinline and noinline, which would
need to be added.
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |