kdb use way3

nlchjian

================================================================================
from: http://blog.csdn.net/xianfengdesign/archive/2008/06/19/2564222.aspx

Debugging the Kernel with KGDB
[url=javascript:d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(saveit=window.open('http://wz.csdn.net/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'saveit','scrollbars=no,width=590,height=300,left=75,top=20,status=no,resizable=yes'));saveit.focus();]收藏[/url]
   
新一篇: Remote Debugging of Loadable Kernel Modules with kgdb: a Knowledge-based Article for Getting Started
|
旧一篇: Debuggers and Related Tools
   
  One of the features of Blackfin uClinux is the inclusion of KGDB over ethernet.
This allows the “normal” operation of the ethernet interface to be
taken over by gdb. Selected UDP ports are then used to communicate
between gdb operating on a host system and a gdb stub or server working
on the target system
To set the system up you need to do the following  

     Patch the Kernel for use with KGDB
   
     Configure the kernel to build in KGDB
   
     Modify the kernel command line
   
     Start the Kernel
   
     Start GDB on a development host
   
     Connect to the target
   
     Debug away
   

  There are some advanced time saving gdb scripts, which can be used with kgdb. Check out the
gdb_snippets
section.
Patch the kernel
  A patch is available to add KGDB to the kernel.
Follow these instructions to apply the patch:
$ cd uClinux-dist/linux-2.6.x
$ patch -p1 kgdb_patch/kgdb_bfin_linux-2.6.x.patch
Configure The Kernel for KGDB
  Once this patch has been applied, configure the kernel.  
make linux_menuconfig
  The KGDB options will be found under the Kernel Hacking section.  
  Kernel hacking --->
   

Kernel debugging
   

KGBD: kernel debugging with remote gdb
      

KGDB: Over Ethernet
  Then exit the Kernel Configuration system and save the selected options.
Modify the kernel command line
When the kernel boot the command line is passed into the kernel
from u-boot in the “bootargs” environment variable or the Kernel
command line can be compiled in to the kernel if required.
To trigger KGDBoe the command line is.  
kgdboe=@target-IP/,@host-IP/
  For example  
kgdboe=@192.168.1.200/,@192.168.1.1/
  This will connect the kgdb running
on the target (the Blackfin board) at 192.168.1.200 to the host
development system (where you compile things) at 192.168.1.1

     The default host mac address will be used
   
     The target will receive GDB messages on UDP port 6443
   
     The target will  send GDB messages on UDP port 6442
   

  To compile this command line into kernel, select:  
Blackfin processor options --->
      Board customizations --->
         

Default bootloader kernel arguments
          (console=ttyBF0,57600 kgdboe=@192.168.1.200/,@192.168.1.1/) Initial kernel command string
Boot the KGDB Kernel
Connect your terminal emulator to the serial port and boot the
kernel image. The target system's IP address will need to be configured
using ifconfig.  
/> ifconfig eth0 192.168.1.200
Start GDB on the Host
  A debug session should be started on the host system  using the bfin-elf-gdb tool. Remember this runs on x86 systems but debugs Blackfin code.
cd uClinux-dist/linux-2.6.x
bfin-elf-gdb vmlinux
Or you can run ddd --debugger bfin-elf-gdb vmlinux if you want to use the ddd debugger.
Connect the Debug Host to the Target
  Once the Debugger has started you can connect to the target system using the UDP protocol and the special Debug port
(gdb) target remote udp:192.168.1.200:6443
Some Sample Debug Commands
     These commands can be used as an example of a debug session.
    # Set a break point at a kernel function (sys_open)
(gdb) break sys_open
# Use the GDB continue command
(gdb) c
   
   
     On the target system use the “ls” command to trigger a breakpoint at sys_open
    /> ls
   
   
     The Breakpoint hits and GDB displays a message
    "Breakpoint 1: sys_open(..."
# Use the gdb single stepping command
(gdb) si
# Use the GDB  remove breakpoint command
(gdb) del 1
# Set hardware breakpoint
(gdb) hbreak sys_open
# Continue
(gdb) c
  - Run "ls" in the target console
/> ls
  - The GDB Session is terminated using the detach command
# Interrupt the target from the GDB host
(gdb) Type Ctrl+C
# Detach the GDB host from the target
(gdb) detach
# Exit GDB
(gdb) quit
   
   
Trouble shooting
  
"Remote communication error: Connection refused"
The ethernet connection is not established. Please check the kernel
boot message (using dmesg), if network connection setting correct, you
should see message like:
Kernel command line: root=/dev/mtdblock0 rw earlyprintk=seri,ua0,57600 kgdboe=@10.99.22.254/,@10.99.22.156/               
kgdboe: local port 6443                                                                                                   
kgdboe: local IP 10.99.22.254                                                                                             
kgdboe: interface eth0                                                                                                     
kgdboe: remote port 6442                                                                                                   
kgdboe: remote IP 10.99.22.156                                                                                             
kgdboe: remote ethernet address ff:ff:ff:ff:ff:ff  
"Remote failure reply: E22"
If the kernel boot message shows the network connect is OK, but gdb
still cannot perform remote debug, there may be message like this:
(gdb) target remote udp:10.99.22.254:6443
warning: The remote protocol may be unreliable over UDP.
Some events may be lost, rendering further debugging impossible.
Remote debugging using udp:10.99.22.254:6443
warning: Invalid remote reply:
Remote failure reply: E22
KGDB uses a simple network stack, if your board and host are both on a LAN, unrecognized network packet may confuse KGDB. Please connect your host with your target with cross over cable.
Using the Serial Uart
  The Serial UART
can also be used to connect a debug host to the target. In this case
typing a Ctrl+A over the serial line will cause the kernel to enter a
debug mode. The Debug host will then send debug commands over the
serial line instead of the ethernet port. This option is useful on
systems that have no ethernet interfaces.
  If you want to do source level debugging over UART and share this UART with console go back to the Kernel Configuration (make linux menuconfig)
Select option “KGDB: on Blackfin UART”. Set “KGDB: UART port number”. Don't forget to change the mode of Blackfin serial driver to PIO (not DMA). Or else, kgdb works incorrectly on UART
  Enable “KGDB: Wait for gdb connection early” if you want connect to kgdb when kernel booting.  
Exit the configuration system save the options and build the kernel.
Boot the kernel Image as above
Ask target to wait for gdb connection by entering Ctrl+A.  (In minicom, you should enter Ctrl+A+A )
Start GDB as for the KGDBoe session Issue the following commands at the gdb prompt  
# Set the baud rate in GDB
(gdb) set remotebaud 57600
# connect to the target
(gdb) target remote /dev/ttyS0
  Continue with debugging as before. All other operations are the same as that in KGDB over Ethernet. The only difference is that after issuing the continue command in GDB, stop the GDB connection using two “Ctrl+C”s  and connect again after breakpoints are hit or Ctrl+A is entered.
debugging kernel modules
Like any other ELF executable, a loadable module is divided up into
several sections. The module loader looks at all of the sections and
lays them out sequentially in memory; after relocating symbols it
forgets about where the sections went. The kernel creates a kobject
onto each loadable module and populates it with a set of attributes
containing the section offsets. Those attributes will show up under /sys/module. Thus, for example, after module foo is loaded, /sys/module/foo/sections/.data will contain the beginning of the .data section. The foo
developer can then fire up gdb and, after connecting to the target
kernel, use the section offset information to issue a command like:
add-symbol-file /path/to/module 0xd081d000 \  # .text
                  -s .data 0xd08232c0 \
    s .bss  0xd0823e20
   
  Thereafter, debugging the module is just like debugging the rest of the kernel. There is a script (below) which generates the add-symbol-file
command, reducing the operation to a simple cut-and-paste. A little
more trickery, and you could do this via rsh, as part of a gdb init script.
#!/bin/sh
#
# gdbline module image
#
# Outputs an add-symbol-file line suitable for pasting into gdb to examine
# a loaded module.
#
cd /sys/module/$1/sections
echo -n add-symbol-file $2 `/bin/cat .text`
for section in .[a-z]* *; do
    if [ $section != ".text" ]; then
        echo  " \\"
        echo -n "       -s" $section `/bin/cat $section`
    fi
done
echo
This produces output like:  
root:~> ./module_helper snd_ad1836 /path/to/module
add-symbol-file /path/to/module 0x8f0000 \
        -s .bss 0x8f3d40 \
        -s .data 0x8f37e8 \
        -s .exit.text 0x8f2634 \
        -s .gnu.linkonce.this_module 0x8f3bc0 \
        -s .init.text 0x33cc780 \
        -s .rodata 0x8f2664 \
        -s .rodata.str1.4 0x8f27a0 \
        -s .strtab 0x8f32c8 \
        -s .symtab 0x8f2d98
================================================================================
material:
   http://www.luv.asn.au/overheads/embedded/kdb.pdf
================================================================================
from: http://oss.lzu.edu.cn/blog/article.php?tid_594.html

[ZT] KGDB Linux kernel source level debugger

               
       
       
               
                        作者: sandstorm   发表日期: 2006-09-01 16:01   
                       
复制链接
               
       
       
               
                       
               
From:
http://kerneltrap.org/node/2572

Documentation/kgdb.txt
==================
KGDB Linux kernel source level debugger
Amit S. Kale [email blocked]
Last updated March 2004.
Introduction:
kgdb is a source level debugger for linux kernel. It is used along with gdb to
debug a linux kernel. Kernel developers can debug a kernel similar to
application programs with use of kgdb. It makes it possible to place
breakpoints in kernel code, step through the code and observe variables.
Two machines are required for using kgdb. One of these machines is a
development machine and the other is a test machine. The machines are
connected through a serial line, a null-modem cable which connects their
serial ports. The kernel to be debugged runs on the test machine. gdb runs on
the development machine. The serial line is used by gdb to communicate to the
kernel being debugged.
This version of kgdb is a lite version. It is available on i386 platform uses
a serial line for communicating to gdb. Full kgdb containing more features and
support more architecture is available along with plenty of documentation at
http://kgdb.sourceforge.net/
Compiling a kernel:
Enable Kernel hacking -> Kernel Debugging -> KGDB: kernel debugging with
remote gdb
Only generic serial port (8250) is supported in the lite version. Configure
8250 options.
Booting the kernel:
Kernel command line option "kgdbwait" makes kgdb wait for gdb connection
during booting of a kernel. If you have configured simple serial port, the
port number and speed can be overriden on command line by using option
"kgdb8250=portnumber,speed", where port numbers are 0-3 for COM1 to COM4
respectively and supported speeds are 9600, 19200, 38400, 57600, 115200.
Example: kgdbwait kgdb8250=0,115200
Connecting gdb:
If you have used "kgdbwait", kgdb prints a message "Waiting for connection
from remote gdb..." on the console and waits for connection from gdb. At this
point you connect gdb to kgdb.
Example:
% gdb ./vmlinux
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyS0
Once connected, you can debug a kernel the way you would debug an application
program.
================================================================================
from: http://blogs.sun.com/eschrock/entry/linux_kernel_debugging_with_kdb
               
Tuesday Sep 07, 2004
   
   
   
Linux Kernel Debugging with KDB
   
   
                    
So it's been a while since my
KMDB post
,
but I promised I would do some investigation into kernel debugging on
the Linux side. Keep in mind that I have no Linux kernel experience.
While I will try to be thorough in my research, there may be things I
miss simply from lack of experience or a good test system. Feel free to
comment on any errors or omissions.
We'll try to solve the same problem that I approached with KMDB in
the last post: a deadlock involving reader-writer locks. Linux has a
choice of two debuggers, kdb and kgdb (though User Mode Linux presents
interesting possibilities). In this post I'll be taking a look at
KDB
.
Fire up KDB
Chances are you're not running a Linux kernel with KDB installed.
Some distros (like Debian) make it easier to download and apply the
patch, but none seems to include it by default (admittedly, I didn't do
a very thorough search). This means you'll have to go download the
patch, apply it, tweak some kernel config variables (CONFIG_KDB and CONFIG_FRAME_POINTER),
recompile/reinstall your kernel, and reboot. Hopefully you've done all
this beforehand, because as soon you reboot you've lost your bug
(possibly forever - race conditions are fickle creatures). Assuming you
were running a kdb-enabled kernel when you hit this bug, you then run:
        # echo "1" > /proc/sys/kernel/kdb
And then press the 'pause' key on your keyboard. Alternatively, you
can hook up a serial console, but I'll opt for the easy way out.
Find our troubled thread
First, we need to find the pid our offending process.  The only way to do this is to use the 'ps'
command to display all processes on the system, and then pick out
(visually) which pid belongs to our 'ps' process. Once we have this
information, we can then use 'btp ' to get a stack trace.
Get the address of the rwlock
This step is very similar to the one we took when using kmdb.  The stack trace produced by 'btp' includes frame pointers like kmdb's $C.
Looking back over my kmdb post, it wasn't immediately clear where I got
that magic starting number - it came from the frame pointer in the
(verbose) stack trace. In any case, we use 'id ' to disassemble the code around our call site.  We then use 'mdr '
to examine the memory where the original value is saved. This gets much
more interesting (painful) on amd64, where arguments are passed in
registers and may not get pushed on the stack until several frames
later.
Without a paddle?
At this point, the next step should be "Find who owns the reader
lock." But I can't find any commands in the kdb manpages that would
help us determine this. Without kmdb's ::kgrep, we're stuck
searching for a needle in a haystack. Somewhere on this system, one or
more threads have referenced this rwlock in the past. Our only course
of action is to try 'bta', which will give us a stack trace
of every single process on the system. With a deep understanding of the
code, a great deal of persistence, and a little bit of luck, we may be
able to pick out the offending stack just by sight. This quickly
becomes impractical on large systems, not to mention difficult to
verify and prone to error.
With KDB we can do some basic debugging tasks, but it still relies
on giant "leaps of faith" to correlate two pieces of seemingly disjoint
data (two thread involved in a deadlock, for example). As a point of
comparison, KDB provides 40 different commands, while KMDB provides 771
(356 dcmds and 415 walkers on my current desktop). Next week I'll look
at kgdb and see if it fills in any of these gaps.
           
================================================================================
from: http://epp.eps.nagoya-u.ac.jp/num-analysis/freebsd/handbook/handbook263.html
FreeBSD Handbook
:
Kernel Debugging
: Debugging a kernel crash dump with kgdb
Previous:
Kernel Debugging
Next:
Post-mortem analysis of a dump
  
20.1. Debugging a kernel crash dump with kgdb
Here are some instructions for getting kernel debugging
working on a crash dump, it assumes that you have enough swap
space for a crash dump.  If you have multiple swap
partitions and the first one is too small to hold the dump,
you can configure your kernel to use an alternate dump device
(in the config kernel line), or
you can specify an alternate using the dumpon(8) command.  
Dumps to non-swap devices,
tapes for example, are currently not supported.  Config your
kernel using config -g.
See
Kernel Configuration
for
details on configuring the FreeBSD kernel.
Use the dumpon(8) command to tell the kernel where to dump
to (note that this will have to be done after configuring the
partition in question as swap space via swapon(8)).  This is
normally arranged via /etc/sysconfig and /etc/rc.  
Alternatively, you can
hard-code the dump device via the `dump' clause in the `config' line
of your kernel config file.  This is deprecated, use only if you
want a crash dump from a kernel that crashes during booting.
Note: In the following, the term `kgdb' refers
to gdb run in `kernel debug mode'.  This can be accomplished by
either starting the gdb with the option -k, or by linking
and starting it under the name kgdb.  This is not being
done by default, however.
When the kernel has been built make a copy of it, say
kernel.debug, and then run strip -d on the
original. Install the original as normal.  You may also install
the unstripped kernel, but symbol table lookup time for some
programs will drastically increase, and since
the whole kernel is loaded entirely at boot time and cannot be
swapped out later, several megabytes of
physical memory will be wasted.
If you are testing a new kernel, for example by typing the new
kernel's name at the boot prompt, but need to boot a different
one in order to get your system up and running again, boot it
only into single user state using the -s flag at the
boot prompt, and then perform the following steps:
  fsck -p
  mount -a -t ufs       # so your file system for /var/crash is writable
  savecore -N /kernel.panicked /var/crash
  exit                  # ...to multi-user
This instructs savecore(8) to use another kernel for symbol name
extraction.  It would otherwise default to the currently running kernel
and most likely not do anything at all since the crash dump and the
kernel symbols differ.
Now, after a crash dump, go to /sys/compile/WHATEVER and run
kgdb.  From kgdb do:
  symbol-file kernel.debug
  exec-file /var/crash/kernel.0
  core-file /var/crash/vmcore.0
and voila, you can debug the crash dump using the kernel sources
just like you can for any other program.
Here is a script log of a kgdb session illustrating the
procedure.  Long
lines have been folded to improve readability, and the lines are
numbered for reference.  Despite this, it is a real-world error
trace taken during the development of the pcvt console driver.
   1:Script started on Fri Dec 30 23:15:22 1994
   2:uriah # cd /sys/compile/URIAH
   3:uriah # kgdb kernel /var/crash/vmcore.1
   4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done.
   5:IdlePTD 1f3000
   6:panic: because you said to!
   7:current pcb at 1e3f70
   8:Reading in symbols for ../../i386/i386/machdep.c...done.
   9:(kgdb) where
  10:#0  boot (arghowto=256) (../../i386/i386/machdep.c line 767)
  11:#1  0xf0115159 in panic ()
  12:#2  0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
  13:#3  0xf010185e in db_fncall ()
  14:#4  0xf0101586 in db_command (-266509132, -266509516, -267381073)
  15:#5  0xf0101711 in db_command_loop ()
  16:#6  0xf01040a0 in db_trap ()
  17:#7  0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
  18:#8  0xf019d2eb in trap_fatal (...)
  19:#9  0xf019ce60 in trap_pfault (...)
  20:#10 0xf019cb2f in trap (...)
  21:#11 0xf01932a1 in exception:calltrap ()
  22:#12 0xf0191503 in cnopen (...)
  23:#13 0xf0132c34 in spec_open ()
  24:#14 0xf012d014 in vn_open ()
  25:#15 0xf012a183 in open ()
  26:#16 0xf019d4eb in syscall (...)
  27:(kgdb) up 10
  28:Reading in symbols for ../../i386/i386/trap.c...done.
  29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
  30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
  31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
  32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
  33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
  34:ss = -266427884}) (../../i386/i386/trap.c line 283)
  35:283                             (void) trap_pfault(&frame, FALSE);
  36:(kgdb) frame frame->tf_ebp frame->tf_eip
  37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
  38:#0  0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
  39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
  40:403             return ((*linesw[tp->t_line].l_open)(dev, tp));
  41:(kgdb) list
  42:398        
  43:399             tp->t_state |= TS_CARR_ON;
  44:400             tp->t_cflag |= CLOCAL;  /* cannot be a modem (:-) */
  45:401     
  46:402     #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
  47:403             return ((*linesw[tp->t_line].l_open)(dev, tp));
  48:404     #else
  49:405             return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
  50:406     #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
  51:407     }
  52:(kgdb) print tp
  53:Reading in symbols for ../../i386/i386/cons.c...done.
  54:$1 = (struct tty *) 0x1bae
  55:(kgdb) print tp->t_line
  56:$2 = 1767990816
  57:(kgdb) up
  58:#1  0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
  59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
  60:       return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
  61:(kgdb) up
  62:#2  0xf0132c34 in spec_open ()
  63:(kgdb) up
  64:#3  0xf012d014 in vn_open ()
  65:(kgdb) up
  66:#4  0xf012a183 in open ()
  67:(kgdb) up
  68:#5  0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
  69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
  70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
  71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
  72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
  73:673             error = (*callp->sy_call)(p, args, rval);
  74:(kgdb) up
  75:Initial frame selected; you cannot go up.
  76:(kgdb) quit
  77:uriah # exit
  78:exit
  79:
  80:Script done on Fri Dec 30 23:18:04 1994
Comments to the above script:
line 6:
This is a dump taken from within DDB (see below), hence the
panic comment ``because you said to!'', and a rather long
stack trace; the initial reason for going into DDB has been
a page fault trap though.
line 20:
This is the location of function trap()
in the stack trace.
line 36:
Force usage of a new stack frame; this is no longer
necessary now.  The stack frames are supposed to point to
the right locations now, even in case of a trap.
(I do not have a new core dump handy , my kernel
did not panic for ia rather long time.)
From looking at the code in source line 403,
there is a high probability that either the pointer
access for ``tp'' was messed up, or the array access was
out of bounds.
line 52:
The pointer looks suspicious, but happens to be a valid
address.
line 56:
However, it obviously points to garbage, so we have found our
error!  (For those unfamiliar with that particular piece
of code: tp->t_line refers to the line discipline
of the console device here, which must be a rather small integer
number.)
  

FreeBSD Handbook
:
Kernel Debugging
: Debugging a kernel crash dump with kgdb
Previous:
Kernel Debugging
Next:
Post-mortem analysis of a dump
================================================================================
from: http://www.kernel.org/pub/linux/kernel/people/jwessel/kgdb/ch03.html
Chapter 3. Enable kgdb for debugging
Prev
   
Next
Chapter 3. Enable kgdb for debugging
Table of Contents
Kernel parameter: kgdbwait
Kernel parameter: kgdb8250
Kernel parameter: kgdboc
Using kgdboc
Kernel parameter: kgdboe
Kernel parameter: kgdbcon
   In order to use kgdb you must activate it by passing configuration
   information to one of the kgdb I/O drivers.  If you do not pass any
   configuration information kgdb will not do anything at all.  Kgdb
   will only actively hook up to the kernel trap hooks if a kgdb I/O
   driver is loaded and configured.  If you unconfigure a kgdb I/O
   driver, kgdb will unregister all the kernel hook points.
   
   All drivers can be reconfigured at run time, if
   CONFIG_SYSFS and CONFIG_MODULES
   are enabled, by echo'ing a new config string to
   /sys/module//parameter/.
   The driver can be unconfigured by passing an empty string.  You cannot
   change the configuration while the debugger is attached.  Make sure
   to detach the debugger with the detach command
   prior to trying unconfigure a kgdb I/O driver.
   
Kernel parameter: kgdbwait
   The Kernel command line option kgdbwait makes
   kgdb wait for a debugger connection during booting of a kernel.  You
   can only use this option you compiled a kgdb I/O driver into the
   kernel and you specified the I/O driver configuration as a kernel
   command line option.  The kgdbwait parameter should always follow the
   configuration parameter for the kgdb I/O driver in the kernel
   command line else the I/O driver will not be configured prior to
   asking the kernel to use it to wait.
   
   The kernel will stop and wait as early as the I/O driver and
   architecture will allow when you use this option.  If you build the
   kgdb I/O driver as a kernel module kgdbwait will not do anything.
   
Prev
   
Next
Chapter 2. Compiling a kernel
Home
Kernel parameter: kgdb8250
================================================================================
from: http://dsrl.cs.fiu.edu/linux-doc/debugging_with_kgdb
Debugging the Linux kernel with KGDB
]]
      
      
        
DSRL Wiki
      
      
   
   
   
      
                     
      
                 
      
      
   
        
      Trace: »
Debugging the Linux kernel with KGDB
         
   
   
  
  
  
  
   
   
−Table of Contents
Debugging the Linux kernel with KGDB
Preparing a kernel
On development machine:
On test machine:

Connecting to Debug Kernel
On test machine
On development machine


More Information

Debugging the Linux kernel with KGDB
Preparing a kernel
To prepare a kernel for testing, apply a KGDB patch to a linux kernel source. Then enable Remote (serial) kernel debugging with GDB from kernel hacking, which will enable KGDB code in the kernel.This will enable choice of a few more config options with change KGDB behavior. These are described below:

Thread analysis: With thread
analysis enabled, gdb can talk to kgdb stub to list threads and to get
stack trace for a thread. This option also enables some code which
helps gdb get exact status of thread. Thread analysis adds some
overhead to schedule and down functions. You can disable this option if
you do not want to compromise on execution speed.
Console messages through GDB: With
this option enabled, kgdb stub will route console messages through GDB.
Console messages from the test machine will appear in a terminal on the
development machine where gdb is running. Other consoles will not be
affected by this option.After the kernel is configured, build it and and add it to Grub. KGDB stub requires following options in a kernel command line.
kgdbwait: This option causes KGDB to wait for a GDB connection during kernel bootup.

kgdb8250=,
Where port number can be 0 to 3 for ports ttyS0(COM1) to
ttyS3(COM4) respectively.Supported port speeds are 9600, 19200, 38400,
57600 and 115200.
An example of above procedure is shown below.  The steps are split between development machine (the machine from which you're debugging) and test machine (the machine running the kgdb patch kernel).
On development machine:
1. Download the 2.6.21.7 kernel from
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.7.tar.gz
, and extract it
$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.7.tar.gz
$ tar xzf linux-2.6.21.7.tar.gz
2. Download and apply the
kgdb patch
. Unzip the kgdb patch and apply one by one as specified below.
$ tar -zxf kgdb-2.6.21.tgz
$ cd linux-2.6.21.7
$ patch -p1
3. Configure the kernel
$ make menuconfig
Configure drivers and other kernel options to enable kgdb, enable following config options (in this order).
Kernel hacking ->

KGDB: kernel debugging with remote gdb ->

     KGDB: Console messages through gdb
Method for KGDB communication (KGDB: On generic serial port (8250)) --->
        ( ) KGDB: Use only kernel modules for I/O
        (X) KGDB: On generic serial port (8250)
--- KGDB: On generic serial port (8250)

     Simple selection of KGDB serial port
         (115200) Debug serial port baud rate
         (0) Serial port number for KGDB
4. Build the kernel
$ make
5.Copy the kernel to target machine
$ tar xzf ../linux-2.6.21.7-kgdb.tgz .
$ scp ../linux-2.6.21.7-kgdb.tgz root@:/usr/src
On test machine:
6. Login as root, go to the /usr/src/linux-2.6.21.7 directory then install the kernel
$ make modules_install
7. Copy the files need to boot and make the initrd image
$ cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.21.7-kgdb
$ cp System.map /boot/System.map-2.6.21.7-kgdb
$ mkinitramfs -o /boot/initrd.img-2.6.21.7-kgdb 2.6.21.7
8. Add to grub entry:
title           , kernel 2.6.21.7 (KGDB)
root            (hd0,1)
kernel          /boot/vmlinuz-2.6.21.7-kgdb root=/dev/sda2 ro splash kgdbwait kgdb8250=1,115200
initrd          /boot/initrd.img-2.6.21.7-kgdb
quiet
Connecting to Debug Kernel
  Set the speed of the serial line on development machine to the value you have given to KGDB kernel on the test machine. Start GDB from the kernel source directory giving it the vmlinux file on command line as the object file. Run the KGDB kernel on the test machine and wait till it prints a message:
Uncompressing Linux... Ok, booting the kernel.
Then connect to the target machine from GDB using target remote
command. This command needs the serial line path to be specified as an
argument. At this point GDB and the KGDB stub will be connected and GDB
will have a control of the target kernel. You can now use
GDB commands for inserting breakpoints, printing values of variables,
breaking and continuing execution. An example of above procedure is
given below:
On test machine
1. Select kgdb kernel from the boot loader prompt, the kernel will start and after doing some initializations, wait for gdb to connect. It will write following prompt on the console:
Uncompressing Linux... Ok, booting the kernel.
On development machine
Here we separate the instructions in what to do if the test machine
is a real machine, and what to do if is a VMWare virtual machine:
Real Machine
2. Set appropriate speed for serial line.
$ stty ispeed 115200 ospeed 115200
3. Start GDB in the same directory were the compiled kernel is locate. It will take some time because vmlinux contains a lot of debugging information.
$ gdb vmlinux
GNU gdb 6.4
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
(gdb)
4. Connect to the test machine using gdb command “target”
(gdb) target remote /dev/ttyS0
VMWare Virtual Machine
2. Power down your virtual machine and click ”Edit Virtual Machine Settings”. Add a serial port, select ”Use a physical serial port on host”, and provide the pipe name ”/tmp/com_1”. Repeat step 1. in the the test machine. 3. GDB can't connect directly to a unix-domain socket, so you'll need to use the socat (“socket cat”) utility.  If the socket created by VMWare is /tmp/com_1, then invoke socat as
$ socat -d -d /tmp/com_1 PTY
Note: most likely it is not installed! please go ahead and install it using
$ aptitude install socat
4. Find the line in the output identifying the PTY that was created (in this case is /dev/pts/2)
2008/03/26 16:51:51 socat[13859] N successfully connected via
2008/03/26 16:51:51 socat[13859] N PTY is /dev/pts/2
2008/03/26 16:51:51 socat[13859] N starting data transfer loop with FDs [3,3] and [4,4]
5. Start GDB in the same directory were the compiled kernel is locate. It will take some time because vmlinux contains a lot of debugging information.
$ gdb vmlinux
GNU gdb 6.4
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
(gdb)
6. Connect to the test machine using gdb command “target” with the port provided by socat
(gdb) target remote /dev/pts/2
More Information

KGDB Homepage

Debugging with GDB

GDB Quick Reference

Using KGDB with VMWare

================================================================================
from: http://lwn.net/Articles/90913/
Debugging kernel modules
[Posted June 23, 2004 by corbet]
               
               
Linus is famously against the use of interactive debuggers on the kernel,
but many developers use them anyway.  Debugging a running kernel is a
little harder than working with a typical application, but it can be done
in a couple of ways.  It is relatively easy to query kernel data
structures in the current running kernel by running gdb with
/proc/kcore as the "core" file.  More extensive debugging,
allowing the use of breakpoints and such, can be done by using gdb
on a remote machine and controlling the target via a serial line or a
network interface.  The -mm tree contains the necessary patches for using
gdb in this mode for a few architectures.
One limitation with using gdb this way is that it can't be used to work
with loadable modules.  The debugger can query the memory used by loadable
modules, set breakpoints there, etc.  The problem is that it does not know
what addresses get assigned to functions and variables when a module is
loaded.  Those addresses, obviously, are not in the core kernel executable,
and there is no real way to find them at run time.  The developer can thus
work by typing in hex addresses directly, but that gets tiresome fairly
quickly.
Your editor was recently finishing out the debugging chapter for Linux
Device Drivers, Third Edition (which is getting closer to ready -
honest) when he ran up against the loadable module problem.  The kernel
knows where all of the symbols go when it loads a module; it really seemed
like it should be possible to communicate that information to a debugger.
A bit of digging revealed that, in fact, the relevant information gets
dropped once the module gets loaded.  So it was time for a fix.
Like any other ELF executable, a loadable module is divided up into several
sections.  The section called .text contains (most of) the module
code itself; .data and .bss contain most of the
variables.  The module loader looks at all of the sections and lays them
out sequentially in (vmalloc) memory; after relocating symbols it forgets
about where the sections went.
If the positions of the sections could be recovered, however, they could be
passed to gdb in the same add-symbol-file command which
tells the debugger about the module code.  The section offsets are all that
gdb needs to figure out where the module's variables live.
Your editor, rather than tell LDD3 readers that symbolic debugging of
kernel modules was impossible, chose to do a little hacking.  The result
was
this patch
, which hangs a new kobject
onto each loadable module and populates it with a set of attributes
containing the section offsets.  Those attributes will show up under
/sys/module.  Thus, for example, after module foo is
loaded, /sys/module/foo/sections/.data will contain the beginning of
the .data section.  The foo developer can then fire up
gdb and, after connecting to the target kernel, use the section
offset information to issue a command
like:
    add-symbol-file /path/to/module 0xd081d000 \  # .text
                -s .data 0xd08232c0 \
                -s .bss  0xd0823e20
Thereafter, debugging the module is just like debugging the rest of the
kernel.  There is a little script (included with the patch) which generates
the add-symbol-file command, reducing the operation to a simple
cut-and-paste.
The patch has been merged into Linus's BitKeeper tree, and will be part of
2.6.8.
           (
Log in
to post comments)
           
           

  Debugging kernel modules
  
    Posted Jun 24, 2004 3:01 UTC (Thu) by jdaily (guest, #604)
       [
Link
]
   
   
Kudos, Jon.  This reminds me of one of the key benefits of man pages (back when software developers used to write man pages): writing the BUGS section would often shame the programmer into fixing the bug.
  
  
  
   
      
   
  
  
  Debugging kernel modules
  
    Posted Jun 24, 2004 3:15 UTC (Thu) by allesfresser (subscriber, #216)
       [
Link
]
   
    Ay, bravo.  Very nice.
  
  
  
   
      
   
  
  
  Impromptu module debugging?
  
    Posted Jun 24, 2004 3:39 UTC (Thu) by speedster1 (subscriber, #8143)
       [
Link
]
   
An interesting use of sysfs... I solved this same problem with 2.4
kernels by modifying the module loader to output the appropriate info.
Do you know if it is possible with the -mm gdb stubs to start up the
kernel normally, then attach a gdb session via serial port later? That
would be awesome coupled with your ever-present module address map --
perfect for tracking down intermittent module weirdness that shows up
once in a blue moon and NEVER when you're purposefully looking for it.
That's the best thing about xmon debugger, that you can run with it
enabled and never notice till a module oopses and you're dropped into
xmon.
-- S. Lockwood-Childs
P.S.
I bet a lot of ppl would love an article that was a case study on using
a kernel debugger to track down some problem (maybe that one is already
in the works, as a natural follow-up to this one?)
  
  
   
      
   
  
  
  How we use GDB on LKMs today
  
    Posted Jun 25, 2004 18:11 UTC (Fri) by giraffedata (subscriber, #1954)
       [
Link
]
   
This is a welcome usability enhancement to GDB with the kernel, but the
situation isn't as dire today as the article makes it sound.
People debug loadable kernel modules with GDB all the time by using
the -m option on 'insmod' to get that section location information.
kgdb.sourceforge.net has a program that does the insmod and generates a
convenient gdb script you can invoke to do the appropriate
add-symbol-file.
The drawback is that you have to plan in advance -- and have to
do a special load of the module. With Jon's work, the information is
always there.
Well, not exactly.  You still have to plan ahead and look at the sysfs
file before gdb gets entered and the system stops.
With current Kgdb (kgdb.sourceforge.net), There's a mechanism where Gdb
automatically knows where the modules are loaded. But something about
it makes Gdb annoyingly slow, so I abandonned it and can't say much
about it.
  
  
   
      
   
  
  
  How we use GDB on LKMs today
  
    Posted Jun 25, 2004 18:37 UTC (Fri) by corbet (editor, #1)
       [
Link
]
   
    "People
debug loadable kernel modules with GDB all the time by using the -m
option on 'insmod' to get that section location information."
Yes, people do that when developing for 2.4 kernels, where insmod has a clue of where the sections live.  In 2.6, the section layout is done inside the kernel itself, so insmod could not tell you where the sections ended up even if it did still support the -m option, which it doesn't...
  
  
  
   
      
   
  
  
  
Debugging kernel modules
  
   
Posted Oct 12, 2004 11:29 UTC (Tue) by mithlesh_t (guest, #13591)
       [
Link
]
   
    The modules which are loaded on machine can very well be debugged using KGDB which can be found at
http://kgdb.sourceforge.net
. There is a patch for GDB which makes it understands that its
debugging modules and kernel instead of normal user land programs. This
patch and other module debugging utilities are available at
http://kgdb.linsyssoft.com
. With these you can debug modules as well as kernel as they are user land programs :)
================================================================================
from: https://linuxlink.timesys.com/forum/1447
      
                       
                      KGDB kernel debug                        
               
               
  
       
  
            September 7, 2006 - 3:45am by Vuha
        
       
I am trying to set up my system for remote kernel debug. My board is
AT91RM9200-EK and I am using TimeSys distributions under Cygwin and
TimeStorm for evaluation purpose.
I can build kernel image via TimeSys Kernel Project from TS. I can remote
debug user space programs. I can build your kernel module template too.
However  I can not to set my environment for remote kernel debug.
There are a few mismatch information in user guides, what I don't
understand. The TC's user guide says that I should rebuild my kernel with
KGDB support. An other document says that there is kernel KGDB support in
TimeSys distribution ( TimeSys distributions 4.0 and later support KGDB for
kernel debugging.). I have downloaded KGDB patch from your Repository. I see
that patch have to install to native 2.6 kernel.
When I have tried to install this patch with "--dry-run" for testing purpose
then I got a lot of error messages. If TimeSys's kernel is incuded KGDB
patch, then why I can't see the KGDB support in menuconfig?
What kind of setting are required to make (to change) your distribution,
that remote kernel debug possibility is being true?
What is the version number of the release Reference Linux Distribution for
ATMEL RM9200 at moment? Where can I find it?
An other problem what results confuse for me.
A)
Release notes of the 9200 distribution says the following:
DISTRIBUTION-SPECIFIC ISSUES
----------------------------
TimeSys is aware of the following issues that are specific to the
TimeSys distribution for the AT91RM9200:
- 00577 - Setting U-Boot "bootargs" causes kernel to hang on boot
  The "bootargs" environment variable in U-Boot is used to specify a
  string of command line parameters to the kernel when it boots.
  Setting this variable causes the kernel to hang during boot.
  The workaround is to hard code the command line in the kernel by
  specifying it when configuring the kernel.
B)
The user_guide_tc.pdf says the following for 2.6 kernel:
Unlike the 2.4 kernel, you do not configure the 2.6 kernel’s initial command
string in the kernel configuration
file. Instead, you must use the bootloader for your target system to
configure the kernel to wait
during startup and to set the baud rate and device for debugging.
What is true out of the above?
Could you give me exact (step by step) description about TimeSys kernel
debug environment setting on the ground of TimeSys's 9200 distribution?
Attila
‹ Problem when compiling RFS

HowTo: Rebuild TimeSys Reference Distribution using TimeStorm? ›
        
   
        
TimeStorm Users

        
   
        
Login
or
register
to post comments
           
  
  
KGDB kernel debug
  
    Submitted by Egan on February 2, 2007 - 11:09am.  
  
   
On Thu, 2006-09-07 at 03:45, Várhelyi Attila wrote:
> I am trying to set up my system for remote kernel debug. My board is
> AT91RM9200-EK and I am using TimeSys distributions under Cygwin and
> TimeStorm for evaluation purpose.
>
> I can build kernel image via TimeSys Kernel Project from TS. I can remote
> debug user space programs. I can build your kernel module template too.
> However  I can not to set my environment for remote kernel debug.
>
> There are a few mismatch information in user guides, what I don't
> understand. The TC's user guide says that I should rebuild my kernel with
> KGDB support. An other document says that there is kernel KGDB support in
> TimeSys distribution ( TimeSys distributions 4.0 and later support KGDB for
> kernel debugging.). I have downloaded KGDB patch from your Repository. I see
> that patch have to install to native 2.6 kernel.
>
> When I have tried to install this patch with "--dry-run" for testing purpose
> then I got a lot of error messages. If TimeSys's kernel is incuded KGDB
> patch, then why I can't see the KGDB support in menuconfig?
>
We have not tested KGDB on the AT91RM9200.  
In general when patching the kernel, you must find a version of the
patch that matches the version of the kernel.  Otherwise you may
encounter mismatches and even hidden incompatibilities.  Although
sometimes if the versions are close you can fix the problems easily
enough by examining the code.
> What kind of setting are required to make (to change) your distribution,
> that remote kernel debug possibility is being true?
> What is the version number of the release Reference Linux Distribution for
> ATMEL RM9200 at moment? Where can I find it?
>
>
The top level Makefile in the kernel source tree specifies the kernel
version:
E.G.
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = .6
On a running linux system the version can be obtained by:
  # uname -a
> An other problem what results confuse for me.
>
> A)
> Release notes of the 9200 distribution says the following:
>
> DISTRIBUTION-SPECIFIC ISSUES
> ----------------------------
>
> TimeSys is aware of the following issues that are specific to the
> TimeSys distribution for the AT91RM9200:
>
> - 00577 - Setting U-Boot "bootargs" causes kernel to hang on boot
>
>   The "bootargs" environment variable in U-Boot is used to specify a
>   string of command line parameters to the kernel when it boots.
>   Setting this variable causes the kernel to hang during boot.
>
>   The workaround is to hard code the command line in the kernel by
>   specifying it when configuring the kernel.
>
>
> B)
> The user_guide_tc.pdf says the following for 2.6 kernel:
>
> Unlike the 2.4 kernel, you do not configure the 2.6 kernel’s initial command
> string in the kernel configuration
> file. Instead, you must use the bootloader for your target system to
> configure the kernel to wait
> during startup and to set the baud rate and device for debugging.
>
> What is true out of the above?
>
The User's Guide tries to provide generic information for many versions
of Linux on many architectures.  
For the AT91RM9200 I believe earlier versions of U-Boot had problems
storing boot arguments (bootargs) correctly.  This was fixed in later
U-Boot versions so it may or may not apply to your board.  Specifying
the command line in the kernel config so that it is compiled into the
kernel is known to work.
These issues are easy to test by simply trying them out.  There's no
magic involved.
Regards,
Tony
> Could you give me exact (step by step) description about TimeSys kernel
> debug environment setting on the ground of TimeSys's 9200 distribution?
>
> Attila
>
> _______________________________________________
> Timestorm-users-list mailing list
> Timestorm-users-list@lists.timesys.com
> https://lists.timesys.com/listinfo/timestorm-users-list
  
  
Login
or
register
to post comments
        
                       
================================================================================
================================================================================
================================================================================
================================================================================
================================================================================
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/47395/showart_1431526.html