Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 32264
Product:  
Component:  
Status: RESOLVED
Resolution: INVALID
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: axel@freakout.de <axel@freakout.de>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
gcc42.tar.gz gcc42.tar.gz application/octet-stream 2007-07-31 18:55 33.71 KB Edit
i8259.tar.gz i8259.tar.gz application/octet-stream 2007-08-01 19:25 67.56 KB Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 32264 depends on: Show dependency tree
Show dependency graph
Bug 32264 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: Opened: 2007-06-08 20:17
        When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3)
- kernel crashes after boot on a VIA C3
        .config: CONFIG_MCYRIXIII=y

Environment:
System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8
16:41:33 CEST 2007 i686 i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu VIA C3 -march=c3
configured with: /home/axel/p/rpm/BUILD/gcc-4.2.0/configure --prefix=/opt/gcc4
--exec-prefix=/opt/gcc4 --srcdir=/home/axel/p/rpm/BUILD/gcc-4.2.0
--enable-shared --enable-languages=c,c++,objc

How-To-Repeat:
        compile vanilla linux kernel 2.4.34.5 with CONFIG_MCYRIXIII=y and boot
the kernel on a VIA C3 -> crash

------- Comment #1 From axel@freakout.de 2007-06-08 20:17 -------
Fix:
        Compile kernel with gcc 4.1.2 Ok and working with -march=c3

------- Comment #2 From Andrew Pinski 2007-06-08 20:19 -------
Testcase?

------- Comment #3 From axel@freakout.de 2007-06-08 20:25 -------
Subject: Re: 03.5:  gcc 4.2.0 compiled vanilla
 kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to pinskia at gcc dot gnu dot org:
> 
> ------- Comment #2 from pinskia at gcc dot gnu dot org  2007-06-08 20:19 -------
> Testcase?
> 

I did not want to copy the whole 2.4.34.5 kernel into the case.
The whole kernel ist the testcase - it compiles fine and crashes
at startup. Identical setup with 4.1.2 works fine.

Axel

------- Comment #4 From Richard Guenther 2007-06-09 10:27 -------
We need this reduced to a managable testcase that gcc miscompiles.

------- Comment #5 From axel@freakout.de 2007-06-10 10:05 -------
Subject: Re:  gcc 4.2.0 compiled vanilla kernel
 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to rguenth at gcc dot gnu dot org:
> 
> ------- Comment #4 from rguenth at gcc dot gnu dot org  2007-06-09 10:27 -------
> We need this reduced to a managable testcase that gcc miscompiles.
> 

Sorry - but kernel debugging in the early boot stage goes far
beyond my capabilities. I tried to gather as much information as
i can. The crash can be reproduced just with the kernel itself,
no modules involved.

I've added an archive with two dirs gcc-4.1.2 and gcc-4.2.0 - in
each dir is the compiled kernel vmlinux and the boot image
vmlinuz, with can be loaded by any bootloader (grub, lilo,
syslinux, loadlin, ...).  i also added the corresponding
System.map's.

The kernel were produced from identical (the same) source trees
with gcc 4.1.2 and gcc 4.2.0 on the same machine.  The gcc 4.1.2
compiled kernel boots until panic - no root fs - works ok.  The
gcc 4.2.0 kernel crashes with this output:

======================================================================
Kernel command line: BOOT_IMAGE=vmlinuz4.434
Initializing CPU#0
Detected 797.420 MHz processor.
Console: colour VGA+ 80x25
Unable to handle kernel paging request at virtual address
f000fec4
 printing eip:
c0295690
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c0295690>]   Not tainted
EFLAGS: 00010017
eax: f00fec4    ebx: 00000000   ecx: 00000037   edx: 00000010
esi: 000994c1   edi: c0105000   ebp: 0008e000   esp: c0251fe4
ds: 0018   es: 0020   ss: 0018
Process swapper (pid: 0, stackpage=c0251000)
Stack: 00000020 c0252290 00000010 00000216 c0252630 c0295ae0
c0100191
Call Trace:

Code: 10 00 f3 a5 ea 19 00 00 90 bf f4 3f 8e d8 8e d0 3f a3 c1 8c
 <0>Kernel panic: Attempted to kill the idle task!
In idle task - not syncing
======================================================================

This output is also in the archive dir of gcc-4.2.0/crash.txt

The working kernel (produced from gcc-4.1.2) prints:
======================================================================
Calibrating delay loop... 1592.52 BogoMIPS
======================================================================
at the point where the gcc-4.2.0 produced kernel crashes with the
above messages.

Hope this helps.

Axel

------- Comment #6 From axel@freakout.de 2007-06-10 13:00 -------
Subject: Re:  gcc 4.2.0 compiled vanilla kernel
 2.4.34.5 crashes when VIA C3 optimized -march=c3

please see:

 http://www.bnhof.de/~ho1158/gcc-4.2.0-Bug-target-32264.tar.bz2

for the kernle files mentioned above. It is too large to attach.

Axel

------- Comment #7 From axel@freakout.de 2007-07-31 18:55 -------
Subject: Re: 03.5:  gcc 4.2.0 compiled vanilla
 kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to pinskia at gcc dot gnu dot org:
> Testcase?
> 

i have tracked down module by module of the kernel
and after all i found the module which caused the
kernel crash - its arch/i386/kernel/i8259.c

in the attachment is the module with compiled versions
with gcc-4.1.2 (working) and gcc-4.2.1 (crashing)
and disassembled text files.

the crash is also reproducable with gcc-4.2.1!

Axel

------- Comment #8 From axel@freakout.de 2007-07-31 18:55 -------
Created an attachment (id=14001) [edit]

------- Comment #9 From Pawel Sikora 2007-08-01 17:37 -------
(In reply to comment #7)

> i have tracked down module by module of the kernel
> and after all i found the module which caused the
> kernel crash - its arch/i386/kernel/i8259.c

diffing assembly dumps for these objects shows that
4.2 output doesn't contain common_interrupt, call_do_IRQ
and IRQ0x$_interrupt code. could you provide the preprocessed
i8259.i file? (hint: --save-temps gcc option).

------- Comment #10 From axel@freakout.de 2007-08-01 19:25 -------
Subject: Re:  gcc 4.2.0 compiled vanilla kernel
 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to pluto at agmk dot net:
> diffing assembly dumps for these objects shows that
> 4.2 output doesn't contain common_interrupt, call_do_IRQ
> and IRQ0x$_interrupt code. could you provide the preprocessed
> i8259.i file? (hint: --save-temps gcc option).
> 

attached i8259.tar.gz with i8259.[ciso] compiled with gcc-4.2.1
--save-temps and kernel 2.4.35.

Axel

------- Comment #11 From axel@freakout.de 2007-08-01 19:25 -------
Created an attachment (id=14004) [edit]

------- Comment #12 From Pawel Sikora 2007-08-02 13:29 -------
(In reply to comment #11)
> Created an attachment (id=14004) [edit]

my gcc-4.2.1 (which is almost like FSF release) produces for attached
preprocessed file reasonable code that contains interrupt routines.

$ gcc -m32 -O2 -march=c3 -fno-strict-aliasing --save-temps -c i8259.i
$ nm i8259.o |grep inter
00000020 t IRQ0x00_interrupt
00000030 t IRQ0x01_interrupt
00000040 t IRQ0x02_interrupt
00000050 t IRQ0x03_interrupt
00000060 t IRQ0x04_interrupt
00000070 t IRQ0x05_interrupt
00000080 t IRQ0x06_interrupt
00000090 t IRQ0x07_interrupt
000000a0 t IRQ0x08_interrupt
000000b0 t IRQ0x09_interrupt
000000c0 t IRQ0x0a_interrupt
000000d0 t IRQ0x0b_interrupt
000000e0 t IRQ0x0c_interrupt
000000f0 t IRQ0x0d_interrupt
00000100 t IRQ0x0e_interrupt
00000110 t IRQ0x0f_interrupt
00000000 t common_interrupt
00000000 D interrupt

the 4.2 object from the first attachment hasn't interrupt code
located in the .text section. it has only .bss entries and this
is a reason of the crash-on-first-interrupt.

$ nm i8259.o_gcc42 |grep inter
00000030 b IRQ0x00_interrupt
00000040 b IRQ0x01_interrupt
00000050 b IRQ0x02_interrupt
00000060 b IRQ0x03_interrupt
00000070 b IRQ0x04_interrupt
00000080 b IRQ0x05_interrupt
00000090 b IRQ0x06_interrupt
000000a0 b IRQ0x07_interrupt
000000b0 b IRQ0x08_interrupt
000000c0 b IRQ0x09_interrupt
000000d0 b IRQ0x0a_interrupt
000000e0 b IRQ0x0b_interrupt
000000f0 b IRQ0x0c_interrupt
00000100 b IRQ0x0d_interrupt
00000110 b IRQ0x0e_interrupt
00000120 b IRQ0x0f_interrupt
00000010 b common_interrupt
00000000 D interrupt


btw, the 4.3 snapshot ICEs on this code ;)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000a4a85c in cpp_interpret_string (pfile=0xf5bd40, from=<value
optimized out>, count=1, to=0x7fff77f942f0, wide=0 '\0')
    at ../../libcpp/charset.c:1334
#2  0x0000000000a4b120 in cpp_interpret_string_notranslate
(pfile=0xffffffffffffffff, from=0xf5f8c3, count=7, to=0x7fff77f94270,
    wide=3 '\003') at ../../libcpp/charset.c:1369
#3  0x0000000000a4e408 in do_linemarker (pfile=0xf5bd40) at
../../libcpp/directives.c:924
#4  0x0000000000a4d36d in _cpp_handle_directive (pfile=0xf5bd40, indented=0) at
../../libcpp/directives.c:468
#5  0x0000000000a53963 in cpp_read_main_file (pfile=0xf5bd40, fname=<value
optimized out>) at ../../libcpp/init.c:518
#6  0x00000000004616c1 in c_common_post_options (pfilename=0xf2a090) at
../../gcc/c-opts.c:1190
#7  0x0000000000689f00 in toplev_main (argc=12, argv=0x7fff77f94508) at
../../gcc/toplev.c:1693
#8  0x00000000004851b9 in main (argc=-1, argv=0xf5f8c3) at ../../gcc/main.c:35

------- Comment #13 From axel@freakout.de 2007-08-02 15:05 -------
Subject: Re:  gcc 4.2.0 compiled vanilla kernel
 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to pluto at agmk dot net:
> 
> my gcc-4.2.1 (which is almost like FSF release) produces for attached
> preprocessed file reasonable code that contains interrupt routines.
> 

the compiler is build form the gnu distribution on this machine and
has compiled lots of packages without a problem. also 2.4.35 kernels
for i386(plain) and P3-optimized work without any problem within the
same build environment and this compiler. what should i verify with
my gcc-4.2.1 installation?

maybe the options for the Linux build system make the difference?:

+ gcc4 --version
gcc4 (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ gcc4 -D__KERNEL__ --save-temps -I/src/kernel/linux-2.4.35-ARX/include \
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing \
-fno-common -fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign \
-pipe -mpreferred-stack-boundary=2 -march=c3 -falign-functions=0
-falign-jumps=0 \
-falign-loops=0 -fno-unit-at-a-time -nostdinc -iwithprefix include \
-DKBUILD_BASENAME=i8259 -c -o i8259.o i8259.c

gcc4: warning: -pipe ignored because -save-temps specified

+ nm i8259.o | grep inter
00000030 b IRQ0x00_interrupt
00000040 b IRQ0x01_interrupt
00000050 b IRQ0x02_interrupt
00000060 b IRQ0x03_interrupt
00000070 b IRQ0x04_interrupt
00000080 b IRQ0x05_interrupt
00000090 b IRQ0x06_interrupt
000000a0 b IRQ0x07_interrupt
000000b0 b IRQ0x08_interrupt
000000c0 b IRQ0x09_interrupt
000000d0 b IRQ0x0a_interrupt
000000e0 b IRQ0x0b_interrupt
000000f0 b IRQ0x0c_interrupt
00000100 b IRQ0x0d_interrupt
00000110 b IRQ0x0e_interrupt
00000120 b IRQ0x0f_interrupt
00000010 b common_interrupt
00000000 D interrupt

------- Comment #14 From Pawel Sikora 2007-08-02 19:42 -------
yup, i see something new :)

please look at line 12137 of i8259.i:

__attribute__((regparm(0))) void call_do_IRQ(void); __asm__(...

as you can see there is a semicolon after call_do_IRQ(void)
and following asm statement isn't treated as a function body.
in this way -O1 -f{no-}unit-at-a-time accidentally produces
different code. it's not a gcc bug.

------- Comment #15 From axel@freakout.de 2007-08-02 19:55 -------
Subject: Re:  gcc 4.2.0 compiled vanilla kernel
 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to pluto at agmk dot net:
> 
> as you can see there is a semicolon after call_do_IRQ(void)
> and following asm statement isn't treated as a function body.
> in this way -O1 -f{no-}unit-at-a-time accidentally produces
> different code. it's not a gcc bug.
> 

but who's bug is it?
what component in my tool-chain is to blame for that?
please give me a tip.

Axel

------- Comment #16 From Pawel Sikora 2007-08-03 19:55 -------
(In reply to comment #15)

> > as you can see there is a semicolon after call_do_IRQ(void)
> > and following asm statement isn't treated as a function body.
> > in this way -O1 -f{no-}unit-at-a-time accidentally produces
> > different code. it's not a gcc bug.
> > 
> 
> but who's bug is it?

it's a kernel bug exposed by recent gcc.

------- Comment #17 From axel@freakout.de 2007-08-04 10:45 -------
Subject: Re:  gcc 4.2.0 compiled vanilla kernel
 2.4.34.5 crashes when VIA C3 optimized -march=c3

According to pluto at agmk dot net:
> > but who's bug is it?
> 
> it's a kernel bug exposed by recent gcc.
> 

i'm still confused? is the kernel on which i
build defect - or the sources of the kernel
i compile are buggy?

lots of questions anyway for me:
in with module? in which line? how to patch?
shouldn't we pass this to the kernel guys?
in which way can i do this most effectively?

Axel

------- Comment #18 From Pawel Sikora 2007-08-05 08:02 -------
(In reply to comment #17)
> Subject: Re:  gcc 4.2.0 compiled vanilla kernel
>  2.4.34.5 crashes when VIA C3 optimized -march=c3
> 
> According to pluto at agmk dot net:
> > > but who's bug is it?
> > 
> > it's a kernel bug exposed by recent gcc.
> > 
> 
> i'm still confused? is the kernel on which i
> build defect - or the sources of the kernel
> i compile are buggy?
> 
> lots of questions anyway for me:
> in with module? in which line?

linux-2.4.35/include/asm-i386/hw_irq.h
contains these evil macros.

> how to patch? shouldn't we pass this to the kernel guys?
> in which way can i do this most effectively?

report this to lkml.

------- Comment #19 From Willy Tarreau 2007-08-05 15:39 -------
Reproduced with trivial code. The reason is very simple : The asm code is
emitted in the .data section, because due to the -fno-unit-at-a-time argument,
the "interrupts" array is declared first and sets the current section to .data.

Interestingly, adding __attribute__ ((section(".text"))) before the function
declaration does not change anything. But adding ".section .text\n" in the asm
statement fixes it.

In fact, -fno-unit-at-a-time does not work on this code under gcc-4.2.1, while
it works with gcc-4.1.1. However, using the recommended -fno-toplevel-reorder
argument fixes the problem. Also, if the "dummy" array below is declared before
the asm statement, then even gcc-4.1.1 emits the code in the .data section.

In all cases, removing -fno-unit-at-a-time produces good code. I still suspect
that because the behaviour is different between 4.1 and 4.2, it might be a
regression in 4.2, but since its replacement works, I'm not sure it's worth
investigating further. I'll work on a fix for linux-2.4.

Trivial example below :

/* the following code may go to .data if compiled with gcc >= 4.1 and
-fno-unit-at-a-time */
void common_interrupt(void);
__asm__( "\n"
         ".align 4,0x90""\n"
         "common_interrupt:\n\t"
         "cld\n\t"
);

/* If dummy is not initialized, the code above goes into .text.
 * If dummy is initialized to zero, the code above goes into .bss
 * If dummy is initialized to non-zero, the code goes into .data
 * If dummy is declared before the code above, then it goes to .data
 * whatever the compiler.
 */
int dummy[1] = { 1 };

------- Comment #20 From Andreas Schwab 2007-08-05 16:05 -------
Nothing of this is the fault of the compiler anyway.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug