Sender: Dubblelee (Star Raw), Letter Area: KernelTech
Title: Establishment of the KGDB debugging environment
Sending station: BBS Shuimu Tsinghua Station (Tue Jan 25 00:21:44 2005), transfer
[Declaration] Lidlu original, this article is for Linux learning, free forwarding, I hope to learn Linux friends
A lot of exchanges, lidlu @ 163.com
KGDB-Linux kernel debugging environment creation
Since the time period, since I just started to contact Linux, everything is in a state of exploitation, in order to create a KGDB kernel
Test environment
I checked a lot of more than a lot of folds, and later finally completed. But I didn't have time to sum up at the time.
Time, write a simple summary, I hope to help those Linux friends who need to build a KGDB environment.
KGDB is a source code-level kernel debugging environment. In other words, it is actually a GDB remote debugger .GDB debugging
Application
The order, it is only necessary to be implemented on one machine, but use the GDB debug core, two machines are required, connected by serial ports.
A machine is called a development host (Host), and another machine is called a target machine (Target), two machines are pre-installed with RE
D Hat Linux 7.3 system.
Host Run the GDB debugger, Target runs the system kernel to be debugged, Host's GDB program is targets through the serial line.
The kernel running in the machine is commissioned and controls. The GDB debugger is a source code level debugging, and the operation system for debugging
The kernel performs setup breakpoints and single-step execution, which can be clearly understood by the kernel's work process and how the application is
The system core is realized.
I. Hardware configuration work:
KGDB is a control process for developing host Host to the target machine through serial port. First, you need to prepare one
Serial line
Connect the two machines. My serial port is connected to the two 9-port gate lines with ordinary network cable, only three
The root line, connect the tip 2, 3, 5 of the serial port. When it is connected, it is necessary to pay attention to the connection between the two serial tubes: 5-5, 2-3
3-2. Tour 2, 3. Because the 9-port serial port 2 is transmitted data, 3 is the receiving data, 5 is grounded.
The test serial port is working properly: (You can directly use the super terminal under Windows), but under Linux
Nothing
with.
On the development of the host:
#stty ispeed 38400 OSPEED 38400 -F / dev / TTYS0 // Sets the speed of the serial port
#cat testfile.txt> / dev / ttys0 // Enter file testfile.txt content into the serial port
TTYS0
On the target host:
Stty ISPEED 115200 OSPEED 115200 -F / DEV / TTYS0 / / Setting serial port rate
Cat / dev / ttys0 // receives the inside of the serial port
Rong and display it on the screen
If you can see TestFile.txt content on the target host screen, in turn, the target machine is issued, the development machine is received, and it also shows it.
Description The serial port is working properly.
II. KGDB specific establishment process
KGDB is a kernel patch that requires a problem with the version. Below I take 2.4.18 kernel as an example, specifically tell the KGDB adjustment
Establishment of the environment.
Development host:
1. Download the kernel source code 2.4.18 and copy this file to / usr / src / directory, record Linux2.4.18,
For it
Create a link file Linux. Download KGDB kernel patch KGDB2.4.18 (KGDB patch download address http: // kgd
B.Linsysoft.com/downloads.htm) to directory / usr / src / linux.
2. Go to the / usr / src / linux directory, execute the command $ patch -p1 KGDB Nuclear patch. 3. Compile the kernel to compile the internal core, please refer to the article. Mainly to implement a few commands a) make menuconfig (character interface) / xconfig (graphical interface), select the option to compile, will Kern El Hacking options Select the option of the Kernel Support for GDB, and the macro in the core code is config_gdb. b) run in turn #make dep #make clean #make bzimage #make modules #make modules_install Generates a new kernel. Two files are generated here: /usr/src/linux/system.map / usr / src / linux / arch / i386 / bzimage And using / usr / src / linux / vmlinux with debug information, afterwards. Target host: Will develop newly generated kernel files on the host system.map, bzimage to the target machine Boot directory, rename For systemkgdb.map and bzimagekgdb. You can use FTP file transfer implementation. Modify the /etc/lilo.conf configuration file, start the file with the newly generated kernel Systemkgdb.map with bzimagekg DB boot system. When the target system is started by this kernel, it will wait for the remote host connection, display information: Waiting for Connection from Remote GDB ..., Go again to the development host: Enter / usr / src / linux directory, run (GDB) SET Remotebaud 38400 (GDB) Target Remote / dev / ttys0 Remote debugging using / dev / ttys0 Breakpoint () at kernel / kgdb.c: 1212 (source code in the source code) 1212: Atomic_SET (& KGDB_SETTING_BREAKPOINT, 0); Warning: Shared Library Handler Failed to Enable Breakpoint (GDB) If the above information appears, it means that the debug environment of KGDB has been established. Enter command C, then see the purpose Standard operator Continue to start until the shell command prompt appears. At this point, you can use the GDB command to set the endpoint to see the kernel function tone on the development host. Use . Three. KGDB debug example I have compiled a simple Socket Client / Server program, and Client is running in addition to developing hosts and goals. Outdoor On another machine, it is also pre-installed with Linux system. Serve program runs on the target, and the two communicate, and open The host is controlled. Program workflow: Server end is waiting for connection after Create, ... accept, if there is a Client connection, Server will feed back a message to the client and continue waiting for the client connection. And the Client will start to serv. ER requires connection, then receives information, and ends after outputting this information on the screen. The method of tracking is to set the interrupt point on Sys_SocketCall in the development host, and then use step to step by trace. Implementation steps: 1. Start KGDB, after opening the machine after the target machine, can be interrupted with Ctrl C with Ctrl C, and make Host take Consolidate Authority. 2. Take the "Break Sys_SocketCall" instruction to set the interrupt point on the Sys_SocketCall function. 3. Take "Cont" release the control and let the distal continue. 4. Execute the Server program on the Target side, then you can see the control back to the Host side, and interrupt SYS_SOCKE TCALL 5. You can now track the core with "Step", "Next". Look at the Linux network core source code, you can know, Socket communication under Linux, various operations for Socket, including Create, Bind, Connect, Send, RECV, etc. are implemented via the SYS_SOCKETCALL system call. So Set breakpoints on the Sys_SocketCall system call in the core core to track the various function call relationships related to the cores involved in the socket communication process. Detailed process can be referred to [2] to sum up: Many kernel debugging tools such as Printk, KDB. PRINTK is very cumbersome, while KDB is displayed The combination The code form, it looks very embarrassed. However, KGDB core debugging is based on source code level debugging, which is debugged with Linux source code. Not Changping. Of course, to implement debugging, first have a quite understanding of the source code, huh, huh. references [1] KGDB Quick Start, http://kgdb.linsysoft.com/quickstart.htm [2] Track Linux TCP / IP core - use remote extent, Cai Pin, Lin Yingda. - ※ Source: · BBS Shuimu Tsinghua Station Smth.org · [from: 219.245.76. *]
