On Fri, 2006-12-29 at 12:51 -0800, George Anzinger wrote: > [EMAIL PROTECTED] wrote: > > Hi, there, > > > > I have applied the 2.6.13 kgdb patch into my 2.6.12 kernel in Intel X86_64 > > Xeon > > motherboard. kgdb can start well and accept gdb commands and reply. For > > example, it can stop at kgdb.c after gdb is connected, allow me issue "info > > regi", "info thr", "next", "step", "continue", and ctrl-C to stop the > > running > > kernel etc. > > > > All seem good except the major step: I cannot switch thread. After seeing > > all > > threads, I issue "thr 20" to switch to another thread. The command returns > > OK, > > and the registers seem to have been changed correctly. But when I issue > > "next" > > or "bt", I found it is still in the old thread. What am I missing? > > You are expecting too much. Kgdb can examine other threads but does not > actually cause the kernel to switch to them. > > If you want to have kgdb stop at some place in another thread while it is > alive (i.e. the current executing thread) you need to place a breakpoint at > that location. What I usually do is to examine the thread with kgdb and then > put a breakpoint at the current instruction in that thread. This can be > complicated by the fact that a lot of kernel code is shared, so...
I did an interesting hack at HP with their third-eye src debugger. The debugger supported running macros on the target. I wrote macros to install my break point if the current process was the one I was interested in when coming out of resume() and to remove my breakpoints when entering switch. > > Switch to the thread and do a bt. > You should see the thread in switch (unless it is SMP and the thread is being > run by another cpu). Look through the bt for the place you really want kgdb > to give you control and set a breakpoint there. This is extremely easy to do with ddd; just a few mouse clicks. > Remember, shared code will > likely cause you to end up in the wrong code. You need to, at the very > least, get beyond switch and all the timeout code. > > You also need to make sure that the kernel will, sometime soon, switch to the > thread of interest. I.e. kgdb will NOT pull a program out of a suspend state > (at least not with out a bit of help from you). > > -- > George > > > > > Here is the register infor befor issuing thread switch command. > > > > (gdb) info regi > > rax 0xffffffff 4294967295 > > rbx 0xffffffff8047f860 -2142767008 > > rcx 0x20 32 > > rdx 0x0 0 > > rsi 0xffffffff80689280 -2140630400 > > rdi 0x0 0 > > rbp 0xffffffff80636f50 0xffffffff80636f50 > > rsp 0xffffffff80525038 0xffffffff80525038 > > r8 0x0 0 > > r9 0x0 0 > > r10 0xffff810128021980 -139633010534016 > > r11 0xe4 228 > > r12 0xa 10 > > r13 0x2aaaaacdd360 46912498422624 > > r14 0x0 0 > > r15 0x2aaaaacdd360 46912498422624 > > rip 0xffffffff80155d4b 0xffffffff80155d4b <breakpoint+123> > > eflags 0x246 582 > > cs 0x0 0 > > ss 0x0 0 > > ds 0x0 0 > > es 0x0 0 > > fs 0x0 0 > > ---Type <return> to continue, or q <return> to quit--- > > gs 0x0 0 > > (gdb) > > > > Here is the thread I want to switch to: > > > > 19 thread 8365 (tom_ext3_1) 0xffffffff803803d0 in thread_return () > > at kernel/sched.c:1481 > > Sending packet: $qThreadExtraInfo,20ab#aa...Ack > > Packet received: 64645f7070617274006c6f636b000000 > > Sending packet: $Hg20ab#d4...Ack > > Packet received: OK > > Sending packet: $g#67...Ack > > Packet received: > > 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c89d85270181ffff489d85270181ffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d0033880ffffffff4600000000000000 > > > > Here is the register info after I issued thread > > > > (gdb) info regi > > rax 0x0 0 > > rbx 0x0 0 > > rcx 0x0 0 > > rdx 0x0 0 > > rsi 0x0 0 > > rdi 0x0 0 > > rbp 0xffff810127923dc8 0xffff810127923dc8 > > rsp 0xffff810127923d48 0xffff810127923d48 > > r8 0x0 0 > > r9 0x0 0 > > r10 0x0 0 > > r11 0x0 0 > > r12 0x0 0 > > r13 0x0 0 > > r14 0x0 0 > > r15 0x0 0 > > rip 0xffffffff803803d0 0xffffffff803803d0 <thread_return> > > eflags 0x46 70 > > cs 0x0 0 > > ss 0x0 0 > > ds 0x0 0 > > es 0x0 0 > > fs 0x0 0 > > ---Type <return> to continue, or q <return> to quit--- > > gs 0x0 0 > > (gdb) > > > > > > Here is the gdb packet exchange information when I issue "next" command > > after > > thread switching: > > > > (gdb) n > > Sending packet: $Hg34b5#ad...Ack > > Packet received: OK > > Sending packet: $g#67...Ack > > Packet received: > > ffffffff0000000060f84780ffffffff2000000000000000000000000000000080926880ffffffff0000000000000000506f6380ffffffff38505280ffffffff00000000000000000000000000000000801902280181ffffe4000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a00004b5d1580ffffffff4602000000000000 > > Sending packet: $Hg20ad#d6...Ack > > Packet received: OK > > Sending packet: $g#67...Ack > > Packet received: > > 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c83d92270181ffff483d92270181ffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d0033880ffffffff4600000000000000 > > Sending packet: $Hg34b5#ad...Ack > > Packet received: OK > > Sending packet: $g#67...Ack > > Packet received: > > ffffffff0000000060f84780ffffffff2000000000000000000000000000000080926880ffffffff0000000000000000506f6380ffffffff38505280ffffffff00000000000000000000000000000000801902280181ffffe4000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a00004b5d1580ffffffff4602000000000000 > > Sending packet: $vCont?#49...Ack > > Packet received: > > Packet vCont (verbose-resume) is NOT supported > > Sending packet: $Hc0#db...Ack > > Packet received: OK > > Sending packet: $s#73...Ack > > Packet received: T05thread:00000000000034b5; > > Sending packet: $g#67...Ack > > Packet received: > > ffffffff0000000060f84780ffffffff2000000000000000000000000000000080926880ffffffff44fd3a80ffffffff506f6380ffffffff38505280ffffffff00000000000000000000000000000000801902280181ffffe4000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a0000525d1580ffffffff4603000000000000 > > Sending packet: $mffffffff80525040,8#99...Ack > > Packet received: 795d1580ffffffff > > Sending packet: $s#73...Ack > > Packet received: T05thread:00000000000034b5; > > Sending packet: $g#67...Ack > > Packet received: > > 000000000000000060f84780ffffffff2000000000000000000000000000000080926880ffffffff44fd3a80ffffffff506f6380ffffffff38505280ffffffff00000000000000000000000000000000801902280181ffffe4000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a0000545d1580ffffffff4603000000000000 > > Sending packet: $s#73...Ack > > Packet received: T05thread:00000000000034b5; > > Sending packet: $g#67...Ack > > Packet received: > > 000000000000000060f84780ffffffff2000000000000000000000000000000080926880ffffffff44fd3a80ffffffff506f6380ffffffff30505280ffffffff00000000000000000000000000000000801902280181ffffe4000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a0000602d1380ffffffff4603000000000000 > > Sending packet: $mffffffff80525030,8#98...Ack > > Packet received: 595d1580ffffffff > > Sending packet: $Z0,ffffffff80155d59,1#18...Ack > > Packet received: OK > > Packet Z0 (software-breakpoint) is supported > > Sending packet: $c#63...Ack > > Packet received: T05thread:00000000000034b5; > > Sending packet: $g#67...Ack > > Packet received: > > 05000000000000000400000000000000406e5f80ffffffff0000000000000000c7b300000000000040c14780ffffffff506f6380ffffffff38505280ffffffff00000000000000000000000000000000000000000000000000000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a00005a5d1580ffffffff9602000000000000 > > Sending packet: $P10=595d1580ffffffff#f3...Ack > > Packet received: > > Sending packet: > > $G05000000000000000400000000000000406e5f80ffffffff0000000000000000c7b300000000000040c14780ffffffff506f6380ffffffff38505280ffffffff00000000000000000000000000000000000000000000000000000000000000000a0000000000000060d3cdaaaa2a0000000000000000000060d3cdaaaa2a0000595d1580ffffffff9602000000000000#3a...Ack > > Packet received: OK > > Sending packet: $z0,ffffffff80155d59,1#38...Ack > > Packet received: OK > > Sending packet: $mffffffff80525040,8#99...Ack > > Packet received: 795d1580ffffffff > > breakpoint () at kernel/kgdb.c:1823 > > 1823 ; > > > > The issue is it is still in kgdb.c, not switch to my tom_ext3_1 thread. > > > > Thanks! > > > > Jinggang > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Kgdb-bugreport mailing list > > Kgdb-bugreport@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport > > > -- Piet Delaney Phone: (408) 200-5256 Blue Lane Technologies Fax: (408) 200-5299 10450 Bubb Rd. Cupertino, Ca. 95014 Email: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
