HelenOS/mips32/msim crashes during boot

[Jakub Jermář]

As of mainline,1486, I am getting the following panic on the barebone default msim build using the current toolchain:

jermar@gorgo:~/software/HelenOS.mainline$ msim -c contrib/conf/msim.conf 
HelenOS bootloader, release 0.4.3 (Sashimi), revision 1486M (jakub@jermar.eu-20120430145154-dhc95fk7mhjlozgx)
Built on 2012-05-06 14:11:05 for mips32
Copyright (c) 2001-2012 HelenOS project

Memory statistics
 0x80001000|0x00001000: CPU map
 0x80002000|0x00002000: bootstrap stack
 0x80003000|0x00003000: boot info structure
 0x80100000|0x00100000: kernel entry point
 0x9fc00000|0x1fc00000: bootloader entry point
 0xbfc056a0|0x1fc056a0: kernel image (570776/125782 bytes)
 0xbfc241f6|0x1fc241f6: ns image (147060/61163 bytes)
 0xbfc330e1|0x1fc330e1: loader image (144786/60392 bytes)
 0xbfc41cc9|0x1fc41cc9: init image (145555/60521 bytes)
 0xbfc50932|0x1fc50932: loc image (155672/65102 bytes)
 0xbfc60780|0x1fc60780: rd image (142629/59317 bytes)
 0xbfc6ef35|0x1fc6ef35: vfs image (166340/69940 bytes)
 0xbfc80069|0x1fc80069: fat image (211392/90447 bytes)
 0xbfc961b8|0x1fc961b8: initrd image (4285440/1241489 bytes)

Inflating components ... initrd fat vfs rd loc init loader ns kernel .
Copying CPU map ... 
Booting the kernel ... 
SPARTAN kernel, release 0.4.3 (Sashimi), revision 1486M (jakub@jermar.eu-20120430145154-dhc95fk7mhjlozgx)
Built on 2012-05-06 14:11:05 for mips32
Copyright (c) 2001-2012 HelenOS project
Detected 2 CPU(s), 32768 KiB free memory

######> Kernel panic on cpu0 due to bad trap 11. <######
Unhandled exception Coprocessor Unusable.

THE=0x80048000: pe=1 thr=0x00000000 task=0x00000000 cpu=0x80040000 as=0x806bc000 magic=0xfacefeed
epc=0x8010dcc0	sta=0x00000002	lo =0x00000001	hi =0x00000000
a0 =0x80060038	a1 =0x00000001	a2 =0x00000000	a3 =0x00000000
t0 =0x00000000	t1 =0x00000000	t2 =0x80060000	t3 =0x80178448
t4 =0xffffff80	t5 =0xfffff800	t6 =0x000000c0	t7 =0xffffffe0
t8 =0xffff0000	t9 =0x000000e0	v0 =0x00002710	v1 =0x80040000
s0 =0x80060000	s1 =0x00000000	s2 =0xffff8000	s3 =0x80048000
s4 =0x80060038	s5 =0x806bc000	s6 =0x00000000	s7 =0x9fc00000
s8 =0x80100000	at =0x00000000	kt0=0x0000000b	kt1=0x00000000
sp =0x8004ff80	ra =0x8010dc74	gp =0x80000000

0x8004fde8: generic/src/debug/stacktrace.o:stack_trace()+0x00000018
0x8004fe10: generic/src/debug/panic.o:panic_common()+0x00000170
0x8004fe58: arch/mips32/src/exception.o:breakpoint_exception()
0x8004fe88: generic/src/interrupt/interrupt.o:exc_dispatch()+0x00000110
0x8004fed0: arch/mips32/src/start.o:exception_handler()+0x000000f8
cpu0: halted

The msim version is 1.3.8.

[Jakub Jermář]

The problem is that gcc generated code which uses CP1 (i.e. FPU) even though msim doesn't have an FPU.

In slab_obj_destroy(), there is:

8011d10c:       44820000        mtc1    v0,$f0

[Jakub Jermář]

The problem goes away (at least for the kernel) when we change -mhard-float to -msoft-float. Unfortunately, there is no guarantee that the compiler will not want to use floating point anyway, in which case the build will fail because of unresolved link references. Anyway, we need to reach a state in which gcc has no ambitions to use FPU at all.

[Martin Decky]

Using the -msoft-float is the strongest option we can use to make the compiler not generate any FPU instructions. Pushed as of mainline,1580.

[Jakub Jermář]

Disabling FPU instructions for all mips32 uspace is probably too conservative. Some of the emulators we use do support floating-point and IMO we could allow FPU isntructions in uspace for those targets.

[Martin Decky]

I agree, but it is better to stay on the safe side. Nobody is using any extensive floating point calculations so far.