lkml.org 
[lkml]   [2001]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.4.15-pre4 compile problem
Date
In article <200111121939.fACJdX309798@danapple.com>,
Daniel I. Applebaum <kernel@danapple.com> wrote:
>
>While compiling 2.4.15-pre4:
>+++++++++++++++
>gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o setup.o setup.c
>setup.c: In function `c_start':
>setup.c:2791: subscripted value is neither array nor pointer

Ugh. That's because a buggy #define on UP in x86.

It should be trivially fixed by changing include/asm-i386/processor.h:

#define cpu_data &boot_cpu_data

to

#define cpu_data (&boot_cpu_data)

in order to get the right parsing order for all users of cpu_data. Ie
just add the parenthesis around the thing.

Oh, well. "Always put parentesis around define-expands" is a really
really good rule. Along with "Always put parenthesis around the
argument expansion too".

Oh, and cleaning up the particular offending user will hide the problem
too, if you just use

cpu_data+*pos

instead of using

&cpu_data[*pos]

in arch/i386/kernel/setup.c: c_start(). Which is cleaner and simpler
anyway, and which is defined by C to be exactly the same thing (as long
as "cpu_data" behaves like a real array, not a broken #define that
depends on operator precedence around it).

I'll do both in my tree. Thanks,

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.061 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site