On Thu, Jul 24, 2008 at 9:57 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > Hi > > On Thu, Jul 24, 2008 at 11:57 AM, amol verule <amol.debian@xxxxxxxxx> wrote: >> hi to all, >> how to debug kernel and vmlinuz using kgdb or kdb.which one is >> better? >> where to use kgdb and kdb? > > kdb: you just need one machine....because you can debug the machine directly... > > kdgb: you need to machines, the debugged machine and debugger > machine...you connect both with serial cable IIRC. > > I think kgdb has several advantages as you can easily trap everything, Yes, kgdb comes with every different version of the kernel, so for the 200+ different GIT....kgdb is available. kgdb seemed to be loved by the embedded community. If u do "make htmldocs", u will find a kgdb internal book inside the Documentation/DocBook subdirectory. Few things here: 1. According to Jason (maintainer of kgdb) kgdb is commented as very stable - except for one outstanding bugs related to SMP multithreaded scenario - cannot remember what is that....but checkout the kgdb mailing list (homepage at: http://kgdb.linsyssoft.com/quickstart.htm). 2. When u used kgdb to debug, don't forget that - if u have multicore - the other CPUs is continually running at the same time....and therefore may change state variables which u thought are paused when u paused at kgdb - they are not. Another source is DMA.....DMA still asynchronously updates the memory even though the current CPU is paused. 3. kgdb .... according to the execution flow (I/O driver must be setup beforehand), is enabled only sometime after kernel bootup - inside common_64.c:cpu_init(), and so anything before cpu_init() (called by trap_init()) u cannot debug using kgdb(). (one of the I/O drivers is to setup serial port). 4. kgdb....not sure how it deals with interrupt handler tracing/debugging.....but the alternative like LTTng....which Matthieu said is able to do interrupt tracing....as it attempt to do away with any unnecessary spin locks (using RCU instead). All these sounds new to me......CMIW..... > from boot code to interrupt handler. While I believe kdb has certain Check out the patches at: ftp://oss.sgi.com/www/projects/kdb/download/v4.4/ For each version of kernel, there is one particular version of patch. For many other versions (200+ over different GIT trees) u may have a problem - have to patch it manually following the same pattern. Never use either one before, but according to: http://www.ibm.com/developerworks/linux/library/l-kdbug/ u have to generate a crash before kdb will be called. And looking into the patch for kdb, searching for traps_32.c (all the interrupt routines are located here): we can see that the kdb() function basically is inserted into a few key functions: die() (which means kernel crash), nmi_error(), do_int3() etc..... So, kdb is triggered only during these scenario. Frank Rowand gave a talk on kgdb internals today (at OLS2008)....but sadly it is not available in the proceedings.....must get the ppt somehow.... > limitation due to its interactivity nature. > > Somebody may CMIIW... > > regards, > > Mulyadi. > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
