All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Fri, 30 May 2003 10:33:29 -0700	[thread overview]
Message-ID: <20030530103329.A848@synopsys.com> (raw)
In-Reply-To: <20030530192240.A7564@prism.co.za>; from berndj@prism.co.za on Fri, May 30, 2003 at 07:22:40PM +0200

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.

  parent reply	other threads:[~2003-05-30 17:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44.0305300919510.3613-100000@sw-55.sedsystems.ca>
2003-05-30 17:22 ` Problem Installing Linux Kernel Module compiled with gcc-3.2.x Bernd Jendrissek
2003-05-30 17:31   ` Kendrick Hamilton
2003-05-30 18:02     ` Bernd Jendrissek
2003-05-30 17:33   ` Joe Buck [this message]
2003-05-30 18:43     ` Bernd Jendrissek
2003-05-30 19:02       ` Joe Buck
2003-05-30 19:36         ` Alan Cox

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=20030530103329.A848@synopsys.com \
    --to=jbuck@synopsys.com \
    --cc=berndj@prism.co.za \
    --cc=gcc@gcc.gnu.org \
    --cc=hamilton@sedsystems.ca \
    --cc=linux-kernel@vger.kernel.org \
    /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.