From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110115020059.GB20238@dinah> References: <20110115020059.GB20238@dinah> Date: Sat, 15 Jan 2011 11:47:27 +0200 Message-ID: From: Pavel Zholkover To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] plan9 go output faults on 9vx but ok on cpu Topicbox-Message-UUID: 993822e6-ead6-11e9-9d60-3106f5b1d025 On Sat, Jan 15, 2011 at 4:00 AM, Anthony Martin wrote: > Pavel Zholkover once said: >> I have no idea what is causing it to die, I've tried adding a bunch of >> INT $3 to see how far in the flow I can get, but all I get this: >> >> 9vx panic: unknown trap/intr: 0x203 >> aborting, to dump core. >> >> for an INT $3 just before >> CALL =A0SI =A0 =A0 =A0// fn() > > This happens because the linker outputs the two bytes > { 0xCD, 0x03 } for an INT $3 instruction but libvx32 > only sends a VXTRAP_BREAKPOINT to 9vx if it sees an > INT3 instruction (a single 0xCC byte). Try using a > 'BYTE $0xCC' instead. > > =A0Anthony Thanks, that did the trick. This is what I get when running goroutines on 9vx with a 0xCC breakpoint compiled in: % goroutines goroutines 69: suicide: sys: breakpoint pc=3D0x00009e44 id: 1 0 id: 1 1 id: 1 2 id: 1 3 id: 1 4 id: 1 5 id: 1 6 id: 1 7 id: 1 8 id: 1 9 % acid 69 /proc/69/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 no symbol information acid: regs() PC 0x00009e44 0x9e44 ?file?:0 SP 0x000560e0 ECODE 0x00000000 EFLAG 0x00000000 CS 0x00000000 DS 0x00000000 SS 0x00000000 GS 0x00000000 FS 0x00000000 ES 0x00000000 TRAP 0x00000003 breakpoint AX 0x0004c0c0 BX 0x0004c0c0 CX 0x0fffffc8 DX 0x00054100 DI 0x00056100 SI 0x000072f8 BP 0x00000000 acid: asm(*PC-32) 0x9e24 0x00009e24 ADDL $0x1ed2c,AX 0x9e29 0x00009e29 MOVL DX,0xfffffff8(AX) 0x9e2c 0x00009e2c MOVL BX,0xfffffffc(AX) 0x9e2f 0x00009e2f MOVL 0x1ed2c,AX 0x9e35 0x00009e35 MOVL 0x30(AX),AX 0x9e38 0x00009e38 MOVL AX,0x24(BX) 0x9e3b 0x00009e3b CALL 0x1c10 0x9e40 0x00009e40 MOVL 0x0(DX),DX 0x9e42 0x00009e42 MOVL 0x0(BX),BX 0x9e44 0x00009e44 INT 3 <=3D=3D=3D we stopped here, runtime.rfork() in src/pkg/runtime/plan9/sys.s 0x9e45 0x00009e45 CALL* SI 0x9e47 0x00009e47 CALL 0x9eac 0x9e4c 0x00009e4c RET 0x72f8 is runtime.mstart as it should... acid: asm(*SI) 0x72f8 0x000072f8 MOVL 0x1ed2c,CX 0x72fe 0x000072fe MOVL 0xfffffff8(CX),CX 0x7301 0x00007301 CMPL 0x0(CX),SP 0x7303 0x00007303 JHI 0x730e 0x7305 0x00007305 XORL DX,DX 0x7307 0x00007307 XORL AX,AX 0x7309 0x00007309 CALL 0x1a75 0x730e 0x0000730e SUBL $0x8,SP 0x7311 0x00007311 MOVL 0x1ed2c,AX 0x7317 0x00007317 MOVL 0xfffffff8(AX),AX 0x731a 0x0000731a MOVL 0x1ed2c,CX 0x7320 0x00007320 MOVL 0xfffffffc(CX),CX 0x7323 0x00007323 MOVL 0x0(CX),CX 0x7325 0x00007325 CMPL CX,AX 0x7327 0x00007327 JEQ 0x7336 0x7329 0x00007329 MOVL $0x1eb80,AX 0x732e 0x0000732e MOVL AX,0x0(SP) 0x7331 0x00007331 CALL 0x81ee 0x7336 0x00007336 MOVL 0x1ed2c,AX 0x733c 0x0000733c MOVL 0xfffffffc(AX),AX 0x733f 0x0000733f MOVL 0x94(AX),AX 0x7345 0x00007345 CMPL AX,$0x0 0x7348 0x00007348 JNE 0x735e 0x734a 0x0000734a CALL 0x2d75 0x734f 0x0000734f MOVL 0x1ed2c,CX 0x7355 0x00007355 MOVL 0xfffffffc(CX),CX 0x7358 0x00007358 MOVL AX,0x94(CX) 0x735e 0x0000735e CALL 0x9e4d 0x7363 0x00007363 CALL 0x74c3 0x7368 0x00007368 ADDL $0x8,SP I can't tell from this why 9vx is dying on me and I don't know how to use acid to debug a child process after rfork, is there something like gdb's set follow-fork-mode child ? Pavel