VirtualBox + kgdb analysis of Linux kernel (v3.4.0-rc3)
https://tthtlc.wordpress.com/2012/06/16/virtualbox-kgdb-analysis-of-linux-kernel-v3-4-0-rc3/
Posted June 16, 2012 by Peter Teoh in
kernel_general.
After compiling the kernel inside VirtualBox, copy out the vmlinux to the host, where “gdb” command is to be issued.
Add “kgdboc=ttyS0,115200 kgdbwait” at the end of the kernel line inside the /boot/grub/grub.cfg. Eg:
linux /boot/xxxxx kgdboc=ttyS0,115200 kgdbwait
Then issue at host level:
socat -d -d /tmp/serial1204 pty
after that “/dev/pts/6” is printed:
2012/06/17 08:04:20 socat[6051.18446744073196852992] N opening connection to AF=1 "/tmp/serial1204"
2012/06/17 08:04:20 socat[6051.18446744073196852992] N successfully connected from local address AF=1 "\x02\xE0"
2012/06/17 08:04:20 socat[6051.18446744073196852992] N successfully connected via s\xD1]\x7E
2012/06/17 08:04:20 socat[6051.18446744073196852992] N PTY is /dev/pts/6
2012/06/17 08:04:20 socat[6051.18446744073196852992] N starting data transfer loop with FDs [3,3] and [4,4]
Use that information below (at the host level):
gdb ./vmlinux
(where vmlinux is the compiled vmlinux image from inside the VirtualBox).
(gdb) set remotebaud 115200
(gdb) target remote /dev/pts/6
Remote debugging using /dev/pts/6
kgdb_breakpoint () at kernel/debug/debug_core.c:987
987 kernel/debug/debug_core.c: No such file or directory.
in kernel/debug/debug_core.c
From above, “No such file” found is because we are not located at the root of the kernel source code. Restarting “gdb ./vmlinux” at the root of the kernel source code, and using the “list” command in gdb, we can list the source code.
(gdb) list
982 void kgdb_breakpoint(void)
983 {
984 atomic_inc(&kgdb_setting_breakpoint);
985 wmb(); /* Sync point before breakpoint */
986 arch_kgdb_breakpoint();
987 wmb(); /* Sync point after breakpoint */
988 atomic_dec(&kgdb_setting_breakpoint);
989 }
990 EXPORT_SYMBOL_GPL(kgdb_breakpoint);
991
From above we can see that the very first breakpoint when kgdb stopped is at 986. So all codes that execute before this point cannot be traced by kgdb. As for how this kgdb_breakpoint() is reached, can be seen from the stacktrace:
(gdb) bt
#0 kgdb_breakpoint () at kernel/debug/debug_core.c:987
#1 0xffffffff810cf486 in kgdb_initial_breakpoint (
new_dbg_io_ops=0xffffffff81c7f9e0) at kernel/debug/debug_core.c:885
#2 kgdb_register_io_module (new_dbg_io_ops=0xffffffff81c7f9e0)
at kernel/debug/debug_core.c:927
#3 0xffffffff813e4d94 in configure_kgdboc ()
at drivers/tty/serial/kgdboc.c:197
#4 0xffffffff81d2709e in init_kgdboc () at drivers/tty/serial/kgdboc.c:219
#5 0xffffffff8100203f in do_one_initcall (fn=0xffffffff81d2708a )
at init/main.c:678
#6 0xffffffff81cf2d53 in do_initcall_level (unused=)
at init/main.c:753
#7 do_initcalls (unused=) at init/main.c:761
#8 do_basic_setup (unused=) at init/main.c:780
#9 kernel_init (unused=) at init/main.c:863
#10 0xffffffff816608e4 in ?? () at arch/x86/kernel/entry_64.S:1204
#11 0x0000000000000000 in ?? ()
Essentially the caller is kernel_init()—> do_basic_setup()—> do_initcalls()—>do_initcall_level()—>do_one_initcall()—>init_kgdboc()—>configure_kgdboc()—>kgdb_register_io_module()—>kgdb_initial_breakpoint()—>kgdb_breakpoint().
By setting breakpoints at “printk”, we can see all the stacktrace when the kernel is printing its output to the dmesg:
(gdb) break printk
Breakpoint 1 at 0xffffffff8164c7c6: file kernel/printk.c, line 753.
(gdb) cont
Continuing.
[New Thread 19]
[Switching to Thread 19]
From above, we can see there is a switching of execution from one thread to another.
Breakpoint 1, printk (
fmt=0xffffffff819ed780 "<6>Refined TSC clocksource calibration: %lu.%03lu MHz.\n") at kernel/printk.c:753
753 }
(gdb) bt
#0 printk (
fmt=0xffffffff819ed780 "<6>Refined TSC clocksource calibration: %lu.%03lu MHz.\n") at kernel/printk.c:753
#1 0xffffffff8101a4a1 in tsc_refine_calibration_work (
work=<value optimized out>) at arch/x86/kernel/tsc.c:915
#2 0xffffffff8106d26a in process_one_work (worker=<value optimized out>,
work=0xffffffff81c18e60) at kernel/workqueue.c:1866
#3 0xffffffff8106e2d5 in worker_thread (__worker=0xffff88003dbb4b80)
at kernel/workqueue.c:1977
#4 0xffffffff81072d63 in kthread (_create=0xffff88003da57d28)
at kernel/kthread.c:121
#5 0xffffffff816608e4 in ?? () at arch/x86/kernel/entry_64.S:1204
#6 0x0000000000000000 in ?? ()
(gdb) cont
Continuing.
[Switching to Thread 1]
Breakpoint 1, printk (fmt=0xffffffff81a37d88 "<6>brd: module loaded\n")
at kernel/printk.c:753
753 }
(gdb) bt
#0 printk (fmt=0xffffffff81a37d88 "<6>brd: module loaded\n")
at kernel/printk.c:753
#1 0xffffffff81d2818b in brd_init () at drivers/block/brd.c:624
#2 0xffffffff8100203f in do_one_initcall (fn=0xffffffff81d2803c <brd_init>)
at init/main.c:678
#3 0xffffffff81cf2d53 in do_initcall_level (unused=<value optimized out>)
at init/main.c:753
#4 do_initcalls (unused=<value optimized out>) at init/main.c:761
#5 do_basic_setup (unused=<value optimized out>) at init/main.c:780
#6 kernel_init (unused=<value optimized out>) at init/main.c:863
#7 0xffffffff816608e4 in ?? () at arch/x86/kernel/entry_64.S:1204
#8 0x0000000000000000 in ?? ()
(gdb) cont
Continuing.
[Switching to Thread 19]
Now boot up all the way by deleting all the breakpoints:
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) cont
Continuing.
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通