Re: port-mips/43431: mips trap handling broken

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

The following reply was made to PR port-mips/43431; it has been noted by GNATS.

From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-mips/43431: mips trap handling broken
Date: Tue, 8 Jun 2010 10:59:43 -0600 (MDT)

 On Mon, 7 Jun 2010, martin%NetBSD.org@localhost wrote:
 
 > init: copying out path `/sbin/init' 11
 > pid 1(init): ABI set to O32 (e_flags=0x1007)
 > trap: pid 1(init): sig 11: cause=0x8 epc=0x50505050 va=0x50505050
 > registers:
 > [ 0]=00000000 [ 1]=00000001 [ 2]=00000000 [ 3]=00000000
 > [ 4]=7dffb918 [ 5]=7fffdc14 [ 6]=00000000 [ 7]=7fffdbfc
 > [ 8]=7fffdc14 [ 9]=50505050 [10]=00000018 [11]=056de450
 > [12]=00000002 [13]=00000003 [14]=00000001 [15]=83f185e0
 > [16]=50505050 [17]=50505050 [18]=50505050 [19]=50505050
 > [20]=50505050 [21]=50505050 [22]=50505050 [23]=50505050
 > [24]=7dfa0000 [25]=7dfac2d8 [26]=00000000 [27]=00000000
 > [28]=7dff7150 [29]=7fffd724 [30]=50505050 [31]=50505050
 > Stopped in pid 1.1 (init) at    netbsd:cpu_Debugger+0x4:        jr      ra
 >                bdslot: nop
 > db> bt
 > cpu_Debugger+4 (804114d0,80360f40,b2,80360f5c) ra 80267524 sz 0
 > trap+35c (804114d0,8,50505050,50505050) ra 801b88e4 sz 144
 > mips32_UserGenException+d8 (804114d0,8,50505050,50505050) ra 0 sz 0
 > User-level: pid 1.1
 >
 > Note the bogus register dump; this would have send a SIGSEGV to init - I
 > assume the args passed to from UserGenException() to trap() are bogus.
 > Maybe this was just a page fault misinterpreted some way?
 
    The register dump should be coming from the user registers saved in the 
 PCB, so presumably are the actual registers at the time of the exception
 (and the contents of some of them being 0x50505050 rather matches the 
 exception PC and virtual address of the fault.  The one major thing I 
 can't figure out, and can't tell from the information that gets printed is 
 how it ended up in DDB.  It looks to me like that should only happen if 
 the exception occurred in kernel mode, which shouldn't have come from 
 mips32_UserGenException.  Perhaps that DEBUG code should also print out 
 the status and type variable;  status is used to set whether the trap is 
 user or not, and sets T_USER in the trap variable - which is then used to 
 control if DDB gets entered.
 
 --
 Michael L. Hitch                       mhitch%montana.edu@localhost
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA