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.
next prev 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.