DragonFlyBSD

Joel K. Pettersson wrote:
> On Tue, Dec 15, 2009 at 2:52 PM, Sascha Wildner
> <swildner@crater.dragonflybsd.org> wrote:
>> commit 40ec0564adaa677a0dab5299bdd491a2245e94a0
>> Author: Sascha Wildner <saw@online.de>
>> Date: Tue Dec 15 15:52:07 2009 +0100
>>
>> Add -Werror to the kernel build.
>> [...]
>
> I'd guess the following is probably related to this. Anyhow:
>
> A user following the development changes of DragonFly, I noted that
> building the kernel now errors out due to warnings of unused variables
> - the ones in question being used only by debug code (KKASSERT, etc.),
> and my kernel config disabling debug options.

I don't think that's the proper way to deal with variables that are only
used in debug statements.

We should add something like this:

#ifndef INVARIANTS
#define __debug_var __attribute__((unused))
#else
#define __debug_var
#endif

and then use

int a __debug_var;

for such variables.

Aggelos

Am 16.12.2009 00:28, schrieb Aggelos Economopoulos:
> I don't think that's the proper way to deal with variables that are only
> used in debug statements.
>
> We should add something like this:
>
> #ifndef INVARIANTS
> #define __debug_var __attribute__((unused))
> #else
> #define __debug_var
> #endif
>
> and then use
>
> int a __debug_var;
>
> for such variables.

That looks like a sound idea. I'm on it (testing kernel builds without
INVARIANTS at the moment).

Sascha

Am 16.12.2009 00:14, schrieb Joel K. Pettersson:
> I'd guess the following is probably related to this. Anyhow:
>
> A user following the development changes of DragonFly, I noted that
> building the kernel now errors out due to warnings of unused variables
> - the ones in question being used only by debug code (KKASSERT, etc.),
> and my kernel config disabling debug options.
>
> The following files have these warnings:
>
> sys/kern/kern_lock.c
> sys/kern/kern_sig.c
> sys/kern/lwkt_thread.c
> sys/kern/vfs_cache.c
> sys/kern/vfs_syscalls.c
> sys/vfs/nfs/nfs_vnops.c
> sys/vfs/hammer/hammer_object.c
> sys/vfs/hammer/hammer_subs.c
> sys/platform/pc32/i386/pmap.c
>
> I don't know if these fit the preferred style of solving this, but
> diffs to remove the warnings (mostly adding #ifdef INVARIANTS) to make
> it build attached. At any rate, having a look at it will quickly show
> where it's located.

I think I've fixed it (as aggelos suggested). Can you try again with
latest master?

Sascha

> I think I've fixed it (as aggelos suggested). Can you try again with
> latest master?
>
> Sascha

It builds as expected.

Joel