On 2016/10/22 6:56, Rin Okuyama wrote:
These results indicate that the problem does not simply come from the
optimization errors nor mips/syscall.c. Now I'm worried if there are
much more serious regressions in GCC5 than I imagined.
In order to examine whether this is a problem with GCC5, I tested
kernels compiled by GCC 4.8.5 from netbsd-7 branch.
(1) Kernel compiled with -O2 seems to work well.
(2) Kernel compiled with -O1 fails into random freezes.
(3) Kernel compiled with -O0 panics due to assertion failure in
mips/syscall.c:
init: copying out path `/sbin/init' 11
pid 1(init): ABI set to N32 (e_flags=0x20000027)
panic: kernel diagnostic assertion "l->l_blcnt == 0" failed: file
"../../../../arch/mips/mips/syscall.c", line 364
kernel: breakpoint trap
Stopped in pid 4.1 (sh) at netbsd:cpu_Debugger+0x10: or
sp,s8,zero
(4) Kernel compiled with "-O0 -DMIPS_SYSCALL_DEBUG" panics due
to address error in kernel mode:
pid 1(init): ABI set to N32 (e_flags=0x20000027)
syscall 197: [0]=0 [1]=0x8000 [2]=0x3 [3]=0x1002
[4]=0xffffffffffffffff [5]=0 [6]=0
...(snip)...
syscall 197: return v0=0x78770000 v1=0xffffffffffffffff
pid 0(system): trap: cpu0, address error (load or I-fetch) in
kernel mode
status=0xffa3, cause=0x10, epc=0xffffffff804504b0,
vaddr=0x3002c000feaee68
tf=0x980000041093bca0 ksp=0x980000041093bde0 ra=0xffffffff804504b0
ppl=0x3002c00
kernel: address error (load or I-fetch) trap
Stopped in pid 0.28 (system) at netbsd:sleepq_block+0x154:
lw v0,48(s8)
May this mean kernel compiled by GCC 4.8.5 with -O2 flag works
just accidentally?