2.4.10 build failure - atomic_dec_and_lock export

2.4.10 build failure - atomic_dec_and_lock export

[Ian Grant]

Trond,

2.4.10 won't link with CONFIG_SMP and i386 CPU selected. I believe the problem 
lies in in the #ifndef atomic_dec_and_lock in lib/dec_and_lock.c. As far as I 
can see this symbol is always defined because it's exported.

The following patch works for me, but I barely understand the kernel build 
machinery(*) so please don't use this without checking it carefully.

Ian

* e.g. I cannot understand why this symbol isn't versioned in the object file.

--- linux/lib/dec_and_lock.c.orig	Tue Oct  2 15:47:44 2001
+++ linux/lib/dec_and_lock.c	Tue Oct  2 16:07:01 2001
@@ -1,3 +1,4 @@
+#include <linux/config.h>
 #include <linux/module.h>
 #include <linux/spinlock.h>
 #include <asm/atomic.h>
@@ -26,7 +27,8 @@
  * store-conditional approach, for example.
  */
 
-#ifndef atomic_dec_and_lock
+#ifdef CONFIG_SMP
+#ifndef CONFIG_HAVE_DEC_LOCK
 int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
 {
 	spin_lock(lock);
@@ -37,4 +39,5 @@
 }
 
 EXPORT_SYMBOL(atomic_dec_and_lock);
+#endif
 #endif

-- 
Ian Grant, Computer Lab., William Gates Building, JJ Thomson Ave., Cambridge
Phone: +44 1223 334420

Re: 2.4.10 build failure - atomic_dec_and_lock export

[Trond Myklebust]

>>>>> " " == Ian Grant <Ian.Grant@cl.cam.ac.uk> writes:

     > Trond,
     > 2.4.10 won't link with CONFIG_SMP and i386 CPU selected. I
     >        believe the problem
     > lies in in the #ifndef atomic_dec_and_lock in
     > lib/dec_and_lock.c. As far as I can see this symbol is always
     > defined because it's exported.

This patch looks very redundant.

If you have CONFIG_SMP defined then atomic_dec_and_lock will never get
defined, and if CONFIG_HAVE_DEC_LOCK is not defined, then
dec_and_lock.c will never even get compiled. Even the config.h include
is superfluous as linux/module.h will include it.

I don't understand though: I have no problems compiling and linking
stock 2.4.10 with CONFIG_M386=y + CONFIG_SMP=y.
Are you sure that you didn't miss a 'make dep' after doing 'make
config'/'make oldconfig'?

Cheers,
   Trond

PS: sorry that you received this mail twice Ian. I didn't notice the
first time around that you had Cced the l-k list.

Re: 2.4.10 build failure - atomic_dec_and_lock export

[Andreas Schwab]

Trond Myklebust <trond.myklebust@fys.uio.no> writes:

|> >>>>> " " == Ian Grant <Ian.Grant@cl.cam.ac.uk> writes:
|> 
|>      > Trond,
|>      > 2.4.10 won't link with CONFIG_SMP and i386 CPU selected. I
|>      >        believe the problem
|>      > lies in in the #ifndef atomic_dec_and_lock in
|>      > lib/dec_and_lock.c. As far as I can see this symbol is always
|>      > defined because it's exported.
|> 
|> This patch looks very redundant.
|> 
|> If you have CONFIG_SMP defined then atomic_dec_and_lock will never get
|> defined

Unless you use CONFIG_MODVERSIONS, which causes atomic_dec_and_lock to be
versioned and defined as a macro via <linux/modversions.h>.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: 2.4.10 build failure - atomic_dec_and_lock export

[Trond Myklebust]

>>>>> " " == Andreas Schwab <schwab@suse.de> writes:

     > Trond Myklebust <trond.myklebust@fys.uio.no> writes:
     > |> If you have CONFIG_SMP defined then atomic_dec_and_lock will
     > |> never get defined

     > Unless you use CONFIG_MODVERSIONS, which causes
     > atomic_dec_and_lock to be versioned and defined as a macro via
     > <linux/modversions.h>.

Oh great... That's going to confound the test in <linux/spinlock.h>
too.

Urgh. Can anybody propose a less ugly solution than EXPORT_SYMBOL_NOVERS()?

Cheers,
   Trond

[patch] 2.4.10 build failure - atomic_dec_and_lock export

[Keith Owens]

On Tue, 2 Oct 2001 19:52:29 +0200, 
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>>>>>> " " == Andreas Schwab <schwab@suse.de> writes:
>
>     > Trond Myklebust <trond.myklebust@fys.uio.no> writes:
>     > |> If you have CONFIG_SMP defined then atomic_dec_and_lock will
>     > |> never get defined
>
>     > Unless you use CONFIG_MODVERSIONS, which causes
>     > atomic_dec_and_lock to be versioned and defined as a macro via
>     > <linux/modversions.h>.
>
>Oh great... That's going to confound the test in <linux/spinlock.h>
>too.
>
>Urgh. Can anybody propose a less ugly solution than EXPORT_SYMBOL_NOVERS()?

Use a second flag when atomic_dec_and_lock() is #defined.  No conflict
with modversions then.

Index: 10.1/lib/dec_and_lock.c
--- 10.1/lib/dec_and_lock.c Wed, 29 Aug 2001 09:36:05 +1000 kaos (linux-2.4/j/21_dec_and_lo 1.1.1.1 644)
+++ 10.1(w)/lib/dec_and_lock.c Wed, 03 Oct 2001 12:24:35 +1000 kaos (linux-2.4/j/21_dec_and_lo 1.1.1.1 644)
@@ -26,7 +26,7 @@
  * store-conditional approach, for example.
  */
 
-#ifndef atomic_dec_and_lock
+#ifndef ATOMIC_DEC_AND_LOCK
 int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
 {
 	spin_lock(lock);
Index: 10.1/include/linux/spinlock.h
--- 10.1/include/linux/spinlock.h Thu, 05 Jul 2001 14:00:51 +1000 kaos (linux-2.4/X/48_spinlock.h 1.1.2.1 644)
+++ 10.1(w)/include/linux/spinlock.h Wed, 03 Oct 2001 12:27:02 +1000 kaos (linux-2.4/X/48_spinlock.h 1.1.2.1 644)
@@ -42,6 +42,7 @@
 #if (DEBUG_SPINLOCKS < 1)
 
 #define atomic_dec_and_lock(atomic,lock) atomic_dec_and_test(atomic)
+#define ATOMIC_DEC_AND_LOCK
 
 /*
  * Your basic spinlocks, allowing only a single CPU anywhere
@@ -128,7 +129,7 @@ typedef struct {
 #endif /* !SMP */
 
 /* "lock on reference count zero" */
-#ifndef atomic_dec_and_lock
+#ifndef ATOMIC_DEC_AND_LOCK
 #include <asm/atomic.h>
 extern int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock);
 #endif