Bug 2391 - undefined reference to `cmpxchg' for 80386 build
Summary: undefined reference to `cmpxchg' for 80386 build
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Luming Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-29 14:18 UTC by Len Brown
Modified: 2004-04-20 20:12 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.4.25-rc1
Tree: Mainline
Regression: ---


Attachments
a patch (2.35 KB, patch)
2004-03-30 00:46 UTC, Luming Yu
Details | Diff
a slightly simpler patch (vs 2.6.5) (2.40 KB, patch)
2004-03-30 10:42 UTC, Len Brown
Details | Diff
simplest patch (vs 2.6.5) (2.01 KB, patch)
2004-03-30 13:55 UTC, Len Brown
Details | Diff

Description Len Brown 2004-03-29 14:18:35 UTC
On Sun, 2004-03-28 at 10:24, Arkadiusz Miskiewicz wrote: 
 
> ACPI uses cmpxchg so it's not possible to build it for i386 it seems. 
> 
> +__acpi_release_global_lock (unsigned int *lock) 
> +{ 
> +       unsigned int old, new, val; 
> +       do { 
> +               old = *lock; 
> +               new = old & ~0x3; 
> +               val = cmpxchg(lock, old, new); 
> +       } while (unlikely (val != old)); 
> +       return old & 0x1; 
> +} 
>  
 
> -o vmlinux 
> drivers/acpi/acpi.o(.text+0x4cf4): In function 
> `acpi_ev_global_lock_handler': 
> : undefined reference to `cmpxchg' 
> drivers/acpi/acpi.o(.text+0x4dc6): In function 
> `acpi_ev_acquire_global_lock': 
> : undefined reference to `cmpxchg' 
> drivers/acpi/acpi.o(.text+0x4e4b): In function 
> `acpi_ev_release_global_lock': 
> : undefined reference to `cmpxchg' 
 
ACPI unconditionally used cmpxchg before this change also -- from asm(). 
The asm() was broken, so we replaced it with C, 
which invokes the cmpxchg macro, which isn't defined for 
an 80386 build. 
 
I guess it is a build bug that the assembler allowed us 
to invoke cmpxchg in an asm() for an 80386 build in earlier releases. 
 
I'm open to suggestions on the right way to fix this. 
 
1. recommend CONFIG_ACPI=n for 80386 build. 
 
2. force CONFIG_ACPI=n for 80386 build. 
 
3. invoke cmpxchg from acpi even for 80386 build. 
 
4. re-implement locks for the 80386 case. 
 
I guess it depends on why one would build 
for 808386 and CONFIG_ACPI=y.  Certainly 
there is no risk of 80386 hardware actually 
running the CMPXCHG in the ACPI code -- 
80386 was EOL'd long before ACPI came out 
and 2.4.25 (and earlier) would have died on us. 
 
I don't like #1 b/c I don't want to get more 
e-mail like this;-) 
 
#2 wouldn't bother me.  But if somebody is 
building for i386 for the purpose for de-tuning 
the compiler and they really do want ACPI support, 
it would bother them. 
 
#3 would be the old behaviour, which also 
wouldn't bother me.  I guess we'd duplicate the 
macro inside the ACPI code so that others didn't 
use it by mistake. 
 
#4 would be an academic exercise, since the code 
would never actually execute on an 80386.
Comment 1 Len Brown 2004-03-29 19:54:32 UTC
Luming, 
Please implement a fix that  
1. builds even when the CPU is set to CONFIG_M386 
and CONFIG_X86_CMPXCHG is not defined. 
 
It looks like the way to do this is to leave system.h alone, 
and to define our own version of the right flavor of __cmpxchg 
 in __cmpxchg in asm-i386/acpi.h 
with a private name, say cmpxchg4_always() and a comment explaining 
why the duplicate code. 
 
2. checks at boot-time via cpuid that cmpxchg is supported by the 
processor and disables ACPI if it is not.   Should be a generic 
named test so that other sub-systems can decide to use it if 
they decide to. 
 
Note that this is i386 issue only, x86_64 doesn't support building without 
the capability. 
 
thanks, 
-Len 
 
Comment 2 Luming Yu 2004-03-30 00:46:25 UTC
Created attachment 2454 [details]
a patch

this is patch based on requirment above.
--Luming
Comment 3 Len Brown 2004-03-30 10:42:27 UTC
Created attachment 2456 [details]
a slightly simpler patch (vs 2.6.5)

This patch is based on and replaces Luming's patch.  It fixes the
comment typo so the patch will build, updates the comments
and deletes some dead code.

The check for X86_FEATURE_CX8 is overkill,
that is the CMPXCHG8B intruction new in the Pentium.
Technically we really want to be checking for the CMPXCHG
instruction which was new in the 486 -- though I doubt
ACPI is deployed on any 486 boxes that would notice
the difference...
Comment 4 Len Brown 2004-03-30 13:55:22 UTC
Created attachment 2458 [details]
simplest patch (vs 2.6.5)

got talked into yet a simpler patch.
define cmpxchg always, system wide
#warning in ACPI code on 80386 build
Comment 5 Len Brown 2004-04-04 21:23:22 UTC
fix (simplest patch) is in 2.6.5 and > 2.4.26-rc1 -- closing.
Comment 6 Denis Pilon 2004-04-20 20:12:29 UTC
FYI:

http://bugzilla.kernel.org/show_bug.cgi?id=2554

drmP.h already defines cmpxchg for i386 kernel builds...so a new bug is 
introduced, as it tries to define it again.

DP

Note You need to log in before you can comment on or make changes to this bug.