Kgdb debugging Under ARM Kernel 2.6.26

Reprinted from http://www.unixresources.net/linux/clf/linuxK/archive/00/00/70/85/708507.html#article709039

I am at a limited level, but I only record the use process. I hope to have some reference for those who have such requirements.

Description of the basic software and hardware environment:
ARM-based Demo Board (Freescale I. MX series) with a UART port and a network port.
Kernel 2.6.26. kgdb is supported. In fact, the 24 kernel version is also acceptable. I have verified it. I have already created a patch based on my company's kernel version, but it is not suitable for you at present. After finishing the patch, check if it can be uploaded.
Due to time issues, I can only perform step-by-step recording in segments. I hope you can provide more support and suggestions.

(1) Check the configuration and basic usage after patching. ^_^ It may be better to adopt the inverted method. First, let's take a look at what kgdb can do, and then consider how to modify the code. The basic principle of kgdb is well known. If you don't know about it, Google. 26 it seems that only UART debugging is supported. After the patch is complete, make menuconfig. If you see the following and select them:
Kernel hacking -->

Kernel debugging

Compile the kernel with debug info

Kgdg: kernel debugging with remote GDB -->

Kgdb: Use kgdb over the serial console
Then, compile the kernel. After compilation, load and start it. Here, you need to modify the startup parameters. For details, see what bootloader is for everyone, but it's almost the same, I use Redboot and add the following parameter settings:
"Kgdboc = ttymxc0, 115200 kgdbwait"
There are three parameters in total. kgdboc/kgdbwait/kgdbcon is not used here. If so, add this parameter, the MSG output to the console is displayed on the gdb debugging platform.
After setting, reset the board. If you see the following information, kgdb starts properly:
"Kgdb: Waiting for connection from remote GDB ..."
At this point, the start is complete on the target, and the next step is to wait for the gdb client connection request from the host. Continue. The content of the previous section.
The client connection is relatively simple. It is best to find the gdb of the target compilation tool chain, such as arm-Linux-GDB, and run: XX-GDB vmlinux in the kernel source code directory. next, set the gdb connection. communicates with target through a serial port.
GDB> target remote/dev/ttys0
After the connection is successful, you can see some print messages, and some RSP code streams will be printed on the target console. OK. Now the interaction between the gdb client and the gdb stub of target can receive the DEBUG command. Set a breakpoint and try it. It should be noted that this was interrupted during the kernel initialization. the specific location of the interruption is different. We can see the startup information, the breakpoint you set must be initialized after this.
(2)

The debugging in the previous section can only complete the debug of the initialization code, such as module_init. Next, let's talk about how to enter the debugging mode and debug the module that is manually loaded after the system is started normally.

Kgdb provides magic_sysrq with the key value 'G '. After the system is started, you can run the following command to enter the debugging mode again: Echo G>/proc/sysrq_trigger In this way, you can set the breakpoint through GDB of the host. The breakpoint has been saved in the kernel, and then return to the console to execute the command and run it at the breakpoint. The system is interrupted. Then you can debug the code from GDB. This time is too busy. It's too late to sort these items. Add the module debugging part later. Upstairs, I personally think you can use it on 2.6.12. If you move the kgdb-related code from the 2.6.26 kernel to your kernel, it should not be a problem. You just need to implement the two UART reads and writes. If your board has two serial ports, it is more convenient to use.