From: David Chatterton <chatz@melbourne.sgi.com>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: David Chinner <dgc@sgi.com>, Tim Shimmin <tes@sgi.com>,
Eric Sandeen <sandeen@sandeen.net>,
xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] Make stuff static
Date: Wed, 22 Nov 2006 13:16:17 +1100 [thread overview]
Message-ID: <4563B2F1.6040603@melbourne.sgi.com> (raw)
In-Reply-To: <1164157783.19915.46.camel@xenon.msp.redhat.com>
Russell Cattelan wrote:
> On Wed, 2006-11-22 at 11:42 +1100, David Chinner wrote:
>> On Tue, Oct 17, 2006 at 05:45:31PM -0500, Russell Cattelan wrote:
>>> On Wed, 2006-10-18 at 07:57 +1000, David Chinner wrote:
>>>> On Tue, Oct 17, 2006 at 05:13:01PM +1000, Tim Shimmin wrote:
>>>>> I thought that for debug, we could stop them from being inline
>>>>> for easier debugging. We could have a STATIC_INLINE :-)
>>>> We could, but I don't think it gains us anything.
>>> I agree with Tim on this.
>>> when I see STATIC in the code it's generally assumed to
>>> be a way to toggle of static on/off. Adding static inline
>>> to the #define STATIC starts to overload the the macro
>>> and creates an obfuscation that isn't immediately obvious.
>>> STATIC_INLINE should be fairly obvious.
>> Ok, so I've had time to look at this again. Here's the definitions
>> of STATIC and STATIC_INLINE for debug and nondebug from the
>> patch (whitespace damaged):
>>
>> Index: 2.6.x-xfs-new/fs/xfs/support/debug.h
>> ===================================================================
>> --- 2.6.x-xfs-new.orig/fs/xfs/support/debug.h 2006-11-22 10:54:37.089984780 +1100
>> +++ 2.6.x-xfs-new/fs/xfs/support/debug.h 2006-11-22 11:30:20.433326839 +1100
>> @@ -38,13 +38,37 @@ extern void assfail(char *expr, char *f,
>>
>> #ifndef DEBUG
>> # define ASSERT(expr) ((void)0)
>> -#else
>> +
>> +#ifndef STATIC
>> +# define STATIC static noinline
>> +#endif
>> +
>> +#ifndef STATIC_INLINE
>> +# define STATIC_INLINE static inline
>> +#endif
>> +
>> +#else /* DEBUG */
>> +
>> # define ASSERT(expr) ASSERT_ALWAYS(expr)
>> extern unsigned long random(void);
>> -#endif
>>
>> #ifndef STATIC
>> -# define STATIC static
>> +# define STATIC noinline
>> +#endif
>> +
>> +/*
>> + * We stop inlining of inline functions in debug mode.
>> + * Unfortunately, this means static inline in header files
>> + * get multiple definitions, so they need to remain static.
>> + * This then gives tonnes of warnings about unused but defined
>> + * functions, so we need to add the unused attribute to prevent
>> + * these spurious warnings.
>> + */
>> +#ifndef STATIC_INLINE
>> +# define STATIC_INLINE static __attribute__ ((unused)) noinline
>> #endif
>>
>> +#endif /* DEBUG */
>> +
>> +
>> #endif /* __XFS_SUPPORT_DEBUG_H__ */
>>
>> ------
>>
>> Is this acceptible to everyone?
> Yup.
>
>> FWIW, there is one other thing that this conversion causes
>> problems with, and that's variable definitions. i.e. we can't
>> use STATIC on them any more because of the "noinline" attribute
>> it has. Do we care about this and if so, any suggestions on
>> how to keep this functionality (a different STATIC_xxx define
>> for structures)?
> So I know things like systemtap kgdb oprofile all work better when
> functions are not static, but what about variables/structures?
> do things really get that confused?
> Maybe we shouldn't worry about conditioning them and just make them
> static
>
I agree with Russell, is there a case for not defining a structure static?
I can't think of one, unless it kdb/lcrash is going to work better if they are
not static in a debug build. Otherwise, we should just use "static" and not
"STATIC". Some for static file variables.
David
--
David Chatterton
XFS Engineering Manager
SGI Australia
next prev parent reply other threads:[~2006-11-22 2:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-29 3:28 [PATCH 1/2] Make stuff static sandeen
2006-10-14 4:31 ` Eric Sandeen
2006-10-16 9:12 ` Timothy Shimmin
2006-10-16 13:49 ` Eric Sandeen
2006-10-16 21:34 ` Eric Sandeen
2006-10-16 23:22 ` David Chinner
2006-10-16 23:55 ` Russell Cattelan
2006-10-17 0:50 ` David Chinner
2006-10-17 1:03 ` Eric Sandeen
2006-10-17 3:09 ` David Chinner
2006-10-17 3:18 ` Nathan Scott
2006-10-18 0:56 ` David Chinner
2006-10-17 7:13 ` Tim Shimmin
2006-10-17 21:57 ` David Chinner
2006-10-17 22:45 ` Russell Cattelan
2006-11-22 0:42 ` David Chinner
2006-11-22 1:09 ` Russell Cattelan
2006-11-22 2:16 ` David Chatterton [this message]
2006-11-22 4:24 ` David Chinner
2006-11-22 4:53 ` David Chatterton
2006-11-22 16:13 ` Eric Sandeen
2006-11-29 7:31 ` David Chinner
2006-11-26 14:05 ` Eric Sandeen
2006-10-18 4:06 ` Timothy Shimmin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4563B2F1.6040603@melbourne.sgi.com \
--to=chatz@melbourne.sgi.com \
--cc=cattelan@thebarn.com \
--cc=dgc@sgi.com \
--cc=sandeen@sandeen.net \
--cc=tes@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.