Bad code generation?

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

  I've attempted to use raidframe a few times when playing with my 
vaxstations, and it always crashed on me.  I was trying this again and it 
was still crashing.  I finally dug into it deeper, and it looks to me like 
there's a problem of bad code generation.

  The panic and stack backtrace:

panic: Segv in kernel mode: pc 8005489e addr 0
Stopped in pid 0.30 (system) at netbsd:upcallret:       function 
"upcallret()", e
ntry-mask 0x7c0
                remqhi  *0x4ac(r0), r6
db> bt
panic: Segv in kernel mode: pc %x addr %x
Stack traceback :
0x867cebb0: upcallret+0x0(0x867cec80)
0x867cec80: trap type=0x8 code=0x0 pc=0x8005489e psl=0x170008
0x867cec4c: rf_CommonCreateLargeWriteDAG+0x64c(0x84876000,0x83d1bd80,0x8390bf70,
0x83bc1d70,0x9,0x83d23e70,0x1,0x80055038,0x1)
0x867ced0c: 
rf_CreateLargeWriteDAG+0x28(0x84876000,0x83d1bd80,0x8390bf70,0x83bc1d70,0x9,0x83d23e70)
0x867ced64: rf_SelectAlgorithm+0x52f(0x83c63e18,0x9)
0x867cee28: rf_State_CreateDAG+0x31(0x83c63e18)
0x867cee7c: rf_ContinueRaidAccess+0x87(0x83c63e18)
0x867ceeac: 
rf_DoAccess+0x9b(0x84876000,0x77,0x1,0x20,0,0x80,0,0x85bee000,0x83bc1d70,0x8)
0x867ceed4: raidstart+0x1f3(0x84876000)
0x867cef30: rf_RaidIOThread+0x75(0x84876000)
0x867cef68: cpu_lwp_bootstrap+0x15(0)

  The instruction that caused the panic:

db> x/i rf_CommonCreateLargeWriteDAG+0x64c
netbsd:rf_CommonCreateLargeWriteDAG+0x64c:      movl    0xe0(r1), *0x8c(r1)

  A disassembly of that section of code:

    141a:       d4 7e           clrf -(sp)
    141c:       d4 7e           clrf -(sp)
    141e:       dd ad cc        pushl 0xffffffcc(fp)
    1421:       fb 0d ef d8     calls $0xd,0 <rf_CreateRaidOneWriteDAG>
    1425:       eb ff ff
                        1424: R_VAX_PC32        rf_InitNode
/home/mhitch/NetBSD-5/src/sys/dev/raidframe/rf_dagffwr.c:369
    1428:       d0 ac 08 51     movl 0x8(ap),r1
    142c:       d0 c1 e0 00     movl 0xe0(r1),*0x8c(r1)
    1430:       d1 8c 00
/home/mhitch/NetBSD-5/src/sys/dev/raidframe/rf_dagffwr.c:370
    1433:       d0 ad cc 52     movl 0xffffffcc(fp),r2
    1437:       d0 c2 8c 00     movl 0x8c(r2),r0
    143b:       50
    143c:       d0 d9 88 00     movl *0x88(r9),0x8(r0)
    1440:       a0 08
/home/mhitch/NetBSD-5/src/sys/dev/raidframe/rf_dagffwr.c:371
    1442:       d0 c2 8c 00     movl 0x8c(r2),r0
    1446:       50
    1447:       7d ad dc a0     movq 0xffffffdc(fp),0x10(r0)
    144b:       10

  And the associated source code from sys/dev/raidframe/rf_dagffwr.c:

   365          /* initialize the Wnp node */
   366          rf_InitNode(wnpNode, rf_wait, RF_FALSE, rf_DiskWriteFunc,
   367                      rf_DiskWriteUndoFunc, rf_GenericWakeupFunc, 1, 1, 
4, 0,
   368                      dag_h, "Wnp", allocList);
   369          wnpNode->params[0].p = asmap->parityInfo;
   370          wnpNode->params[1].p = xorNode->results[0];
   371          wnpNode->params[2].v = parityStripeID;

  At offset 0x1428 (line 369), asmap is loaded into r1 from 8(ap), and 
loads what I presume is parityInfo from 0xe0(r1), but then tries to write 
it to *0x8c(r1), which is most certainly incorrect.  The following line of 
code loads r2 from 0xffffffcc(fp), which is wnpNode and uses that to store 
xorNode->results[0], as well as ParityStripID from the next line.

  I'm going to try to rebuild with a different optimization level for 
rf_dagffwr.c and see if it generates correct code.


--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA