2001-10-02 15:18:33

by Ian Grant

[permalink] [raw]
Subject: 2.4.10 build failure - atomic_dec_and_lock export

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



2001-10-02 16:19:20

by Trond Myklebust

[permalink] [raw]
Subject: Re: 2.4.10 build failure - atomic_dec_and_lock export

>>>>> " " == Ian Grant <[email protected]> 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.

2001-10-02 16:39:49

by Andreas Schwab

[permalink] [raw]
Subject: Re: 2.4.10 build failure - atomic_dec_and_lock export

Trond Myklebust <[email protected]> writes:

|> >>>>> " " == Ian Grant <[email protected]> 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
[email protected] 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

2001-10-02 17:52:27

by Trond Myklebust

[permalink] [raw]
Subject: Re: 2.4.10 build failure - atomic_dec_and_lock export

>>>>> " " == Andreas Schwab <[email protected]> writes:

> Trond Myklebust <[email protected]> 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

2001-10-03 02:53:04

by Keith Owens

[permalink] [raw]
Subject: [patch] 2.4.10 build failure - atomic_dec_and_lock export

On Tue, 2 Oct 2001 19:52:29 +0200,
Trond Myklebust <[email protected]> wrote:
>>>>>> " " == Andreas Schwab <[email protected]> writes:
>
> > Trond Myklebust <[email protected]> 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