Date: Fri, 30 May 2003 10:33:29 -0700
From: Joe Buck <jbuck@synopsys.com>
To: Bernd Jendrissek <berndj@prism.co.za>
Cc: Kendrick Hamilton <hamilton@sedsystems.ca>, gcc@gcc.gnu.org,
       linux-kernel@vger.kernel.org
Subject: Re: Problem Installing Linux Kernel Module compiled with gcc-3.2.x
Message-ID: <20030530103329.A848@synopsys.com>
References: <Pine.LNX.4.44.0305300919510.3613-100000@sw-55.sedsystems.ca> <20030530192240.A7564@prism.co.za>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030530192240.A7564@prism.co.za>; from berndj@prism.co.za on Fri, May 30, 2003 at 07:22:40PM +0200
Sender: linux-kernel-owner@vger.kernel.org

On Fri, May 30, 2003 at 07:22:40PM +0200, Bernd Jendrissek wrote:

> If you look at linux/include/linux/spinlock.h, you'll see:
> 
> /*
>  * Your basic spinlocks, allowing only a single CPU anywhere
>  *
>  * Most gcc versions have a nasty bug with empty initializers.
>  */
> #if (__GNUC__ > 2)
>   typedef struct { } spinlock_t;
>   #define SPIN_LOCK_UNLOCKED (spinlock_t) { }
> #else
>   typedef struct { int gcc_is_buggy; } spinlock_t;
>   #define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
> #endif

Yuk!  What is the benefit of introducing this incompatibility?  #ifdefs
are harmful to maintainance, and it's only one word, so why not always
put in the dummy struct member?

> Hmm, actually I thought the kernel had a mechanism to prevent a GCC 3.x
> module from being loaded into a GCC 2.x kernel and vice versa?

Is there any reason, other than the above-described bit of evil, for doing
this (forbidding mixing)?  It prevents the bug-finding approach I
described earlier (a binary search for finding miscompiled code) from
working.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/