Reprinted.
statement:
The content of this note is not original, 90% comes from the integration of online materials. Also, because he is new to qemu & gdbserver remote debug, there is a lot of money tutorial paper, a nice ring only for reference only.
-------------------------------------------------- ----------------------------------------------Dividing line-- -------------------------------------------------- -----------------------
step 1: kernel build environment installation
apt-cache search build-essential sudo apt-get install build-essential -y apt-cache search libncurses-dev sudo apt-get install libncurses-dev -y
Of course, you may also need some other tools, if gcc g ++ make such tools, after all, build-essential toolbox is a child, if a little older, probably a little conflict. The ncurses-dev, this is a must have, I remember directly on the fedora yum install ncurses-dev can, .deb series seems to be added a prefix.
step 2: gdb installation
Need to tell that, build-essential should be included in a gdb & gdbsever tool, but I am sorry that is not available, this error occurs:
Remote 'g' packet reply is too long:000000000000000020000000000000004000000000000000001006000000000000f009000000000028aece81ffffffff981fc081ffffffff901fc081ffffffff0030c1010000000000000000000000000000000000000000f0b926020000000020f1d281ffffffffb01fc081ffffffff00e0e681ffffffff0010e781ffffffff02fbd281ffffffff9600000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000.
So, we need to download a relatively new gdb source (I used 7.8), the URL is: http://ftp.gnu.org/gnu/gdb/
http://ftp.gnu.org/gnu/gdb/
Then follow people to share information out of the network before, modified gdb source: Modify part in static void process_g_packet gdb-7.8 / gdb / remote.c files (struct regcache * regcache) function inside, as follows:
1 static void
2 process_g_packet (struct regcache *regcache)
3 {
4 struct gdbarch *gdbarch = get_regcache_arch (regcache);
5 struct remote_state *rs = get_remote_state ();
6 struct remote_arch_state *rsa = get_remote_arch_state ();
7 int i, buf_len;
8 char *p;
9 char *regs;
10
11 buf_len = strlen (rs->buf);
12
13 /* Further sanity checks, with knowledge of the architecture. */
14 /* if (buf_len > 2 * rsa->sizeof_g_packet)
15 error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
16 */
17 /*modify by xx*/
18 if (buf_len > 2 * rsa->sizeof_g_packet) {
19 rsa->sizeof_g_packet = buf_len;
20 for (i = 0; i < gdbarch_num_regs(gdbarch); i++) {
21 if (rsa->regs[i].pnum == -1)
22 continue;
23 if (rsa->regs[i].offset >= rsa->sizeof_g_packet)
24 rsa->regs[i].in_g_packet = 0;
25 else
26 rsa->regs[i].in_g_packet = 1;
27 }
28 }
29 //.......
30 }
31 }
32 }
Lines 14-15 above are from the original file, and lines 18-27 are re-added. <In order to save layout, I did not paste the back, so pay attention to the syntax errors that may result from "{}"> The principle is not clear to me, but it does solve the problem.
After the modification is complete, start compiling gdb. Execute the following command under gdb-7.8 /:
1 ./configure --prefix=../../tools/ 2 make 3 make install
Note that in the gdb-7.8 / Makefile file directory and does not need to use ./configure to produce. During configuration, if you want to specify the path (directory) of gdb installation, you need to keep up with the relevant parameters of --prefix = $ PATH. In general, this situation may be for the system that already has a gdb but cannot be used. Not deleted, then the newly compiled gdb may need to be installed in another directory. Of course, I myself was installed in ../../tools/ directory.
step 3: Compile linux kernel
Www.kernel.org to download the version they need, to be completed on the kernel compiled bzImage & vmlinux file. If you are just getting started like me, you can refer to the following commands & steps:
cd linux-3.12.35/ cp /boot/config-3.13.0-43-generic .config make menuconfig <save> make bzImage
It should be noted, which depends on the specific debugging information, you should make menuconfig to configure the time, to select and save the good, the compiler. After compilation, bzImage is compressed and used by the qemu virtual machine. Some information is included in vmlinux. There is no compression and it is used by gdb.
When the compilation ends, you can copy vmlinux bzImage file into a clean directory, right --- this with their own habits, do not copy it does not matter.
Above forget the most important things ready: qemu
step 4: qemu use
Simple say: qemu is a virtual machine can emulate x86 & arm and so on hardware platform <seem to be a lot of analog hardware platform ...>, and qemu also embedded a gdbserver. The gdbserver so he can constitute a remote gdb and partners, through ip: network or the way to work through the serial port / dev / ttyS *, in which a head and one at the other end.
As installed qemu virtual machine, you can compile the source code, make & make install, can be downloaded here: http://wiki.qemu.org/Download . Can also be directly apt-get install qemu-kvm ubuntu to the software package. Not detailed here. After installation, these files are possible:
1 qemu-system-i386 2 3 qemu-system-x86_64 4 5 qemu-img 6 7 qemu-io 8 ....
What does this mean? The first line represents the qemu virtual machine used on the i386 machine, and the second line represents the virtual machine used on x86_64. The other ones have not been used. Please refer to the specific document examiner network: http://wiki.qemu.org/Main_Page . Of course, my own system is x86_64, and the second one is used.
step 4: Let kernel take a moment for you ~
1 qemu-system-x86_64 -kernel ./bzImage -initrd ./initrd.img -smp 2 -gdb tcp::1234 -S
Start qemu with the command first.
There are many parameters of qemu-system-x86_64, here is a brief introduction:
-kernel is to specify a large kernel file, and it is bzImage that will do the trick.
-initrd is designated a initrd.img file, the file can be copied comes from /boot/initrd.img-3.13.0-43-generic, about it is what is it? You can refer to this: http://www.linuxfly.org/post/94/ , or is this http://blog.csdn.net/chrisniu1984/article/details/3907874 .
-smp can guess from the name, it is designated to qemu several processors or several threads <ah, it probably means you thread>.
-gdb start qemu is embedded gdbserver, listening to a local tcp port 1234. --- If you write: -gdb tcp: 192.168.1.100: 1234, also seems to be no problem.
-S is pending gdbserver, let gdb remote connect it. There is also a -s, which is another situation to use.
If you find it difficult to type the command <although that is cool>, you can use the following method to save the command to a file, such as qemu.start:
1 #!/bin/bash 2 qemu-system-x86_64 -kernel ./bzImage -initrd ./initrd.img -smp 2 -gdb tcp::1234 -S 3 <save> 4 chmod +x qemu.start 5 6 ./qemu.start
This will start the qemu <path to their attention bzImage & initrd.img file>
Tip: man qemu-system-x86_64, you will get some help.
Step 5: Use gdb to connect the qemu that has been started:
1 ../tools/gdb/bin/gdb vmlinux
2
3 -----
4 GNU gdb (GDB) 7.8
5 Copyright (C) 2014 Free Software Foundation, Inc.
6 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
7 This is free software: you are free to change and redistribute it.
8 There is NO WARRANTY, to the extent permitted by law. Type "show copying"
9 and "show warranty" for details.
10 This GDB was configured as "x86_64-unknown-linux-gnu".
11 Type "show configuration" for configuration details.
12 For bug reporting instructions, please see:
13 <http://www.gnu.org/software/gdb/bugs/>.
14 Find the GDB manual and other documentation resources online at:
15 <http://www.gnu.org/software/gdb/documentation/>.
16 For help, type "help".
17 Type "apropos word" to search for commands related to "word"...
18 Reading symbols from vmlinux...done.
19 -----
20
21 (gdb) target remote : 1234
22 Remote debugging using : 1234
23 0x0000000000000000 in irq_stack_union ()
24
25 (gdb) b start_kernel
26 Breakpoint 1 at 0xffffffff81d2fb02: file init/main.c, line 476.
27
28 (gdb) c
29 Continuing.
30
31 Breakpoint 1, start_kernel () at init/main.c:476
32 476 {
33
34
35 (gdb) n
36 485 smp_setup_processor_id();
37 (gdb) n
38 491 boot_init_stack_canary();
39 (gdb) n
40 493 cgroup_init_early();
The first line indicates to start my own compiled gdb, there are two ways: gdb fileName starts, or after gdb starts, then use file fileName to start
Line 21 indicates that the remote gdbserver is connected. Since this is on the same laptop, the ip address is not specified, only the port number is indicated. ---- Of course, if it is connected to the uart port, it will do.
Line 25 is to break a breakpoint at the entrance of a function.
Line 28 should be a command to let qemu continue to run. At this time, qemu's screen will flash: "Booting from ROM ..."
Behind, it means the next step: next ... next ... Of course, you can also choose step step s .... Until where will the message be printed on qemu? Only after console_init (); this line of code.
To make a slightly important note: I have not enabled the file system here. If necessary, you can try to use busybox to make one, and then refer to the qemu kernel debugging manual, or network resources to join the debugging.
-------------------------------------------------- ------------------------------------ Dirty dividing line ----------- -------------------------------------------------- -------------------------------
postscript:
As for the gdb commands, there are many, many, if it is new to kernel, please click here: http://www.sourceware.org/gdb/ The best thing is to slowly nibble the official website documentation, and then look at others' understanding , It should be almost the same. Or take a look at this: http://www.yolinux.com/TUTORIALS/GDB-Commands.html
I have been searching for kernel debug methods these days, qemu + gdb is one way, of course, there are other methods. But to sum up, the cost is the smallest with qemu + gdb. If you are a large-screen PC, you can try to include qemu + gdb + eclipse into the IDE environment. And if you are a notebook, you don't make an IDE, it is enough under the vim shell.
A little mixed thoughts: I also read some operating system books + Linux kernel introductory readings, but I have never had the opportunity to try to run the following kernel in one step to see how it goes. : Either two computers, or the one that you will give up in half>. Over time, it will slack off, let alone look at the code in detail. Linux kernel is really great, but there is no need to myth it. If you have a certain level of understanding of operating system principles and program design, you can also make an entire OS-although it may be rough. Therefore, the unity of knowledge and action is also necessary.
Finally, if you are really interested in kernel, you must at least engage in English, and then pay attention to kernel MailList as soon as possible-although it is inseparable, but the world is also changing. The book has a time limit.
