在Qemu中使用GDB调试Linux内核无法达到功能或给定地址 [英] Debugging Linux Kernel using GDB in qemu unable to hit function or given address

问题描述

我正在尝试在qemu环境中使用GDB逐步了解内核启动顺序.

I am trying to understand kernel bootup sequence step by step using GDB in qemu environment.

以下是我的设置:

在一个正在运行的终端中

In one terminal im running

~/Qemu_arm/bin/qemu-system-arm -M vexpress-a9 -dtb ./arch/arm/boot/dts/vexpress-v2p-ca9.dtb -kernel ./arch/arm/boot/zImage -append "root=/dev/mmcblk0 console=ttyAMA0" -sd ../Images/RootFS.ext3 -serial stdio -s -S

在其他终端

arm-none-linux-gnueabi-gdb vmlinux
Reading symbols from vmlinux...done.
(gdb) target remote :1234
Remote debugging using :1234
0x60000000 in ?? ()

我的问题是/arch/arm/boot/compressed/*文件中的代码的设置断点如何.

My question is how setup breakpoint for the code in /arch/arm/boot/compressed/* files .

例如，我尝试为misc.c中定义的decompress_kernel设置断点.

e.g I tried to setup break point for decompress_kernel defined in misc.c .

案例1:

(gdb)  b decompress_kernel
Function "decompress_kernel" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (decompress_kernel) pending.
(gdb) c
Continuing.

上面的一个无法点击qemu正在启动的功能.

The above one is not able to hit the function qemu is booting.

案例2:

(gdb) b *0x80008000
Breakpoint 1 at 0x80008000: file arch/arm/kernel/head.S, line 89.
(gdb) c
Continuing.

在这种情况下，qemu也无法启动.

In this case also its not able to hit instead qemu is booting up.

案例3:

(gdb) b start_kernel
Breakpoint 1 at 0x8064d8d8: file init/main.c, line 498.
(gdb) c
Continuing.

Breakpoint 1, start_kernel () at init/main.c:498
498 {
(gdb) 

在这种情况下，功能正在运行，并且我能够逐步调试.

In this case function is hitting and i am able debug step by step.

注意:我已启用调试功能，早期的printk并尝试了hbreak

Note: I have enabled debug,Early printk and tried hbreak

所以我的查询是:

1. 为什么某些功能无法达到断点?
2. 这是qemu限制吗?还是我需要启用更多功能?
3. 我需要附加任何额外的参数吗?
4. 如何调试早期的内核启动

推荐答案

您无法在start_kernel之前的任何函数上放置断点，因为您没有为它们加载符号.实际上，您是使用内核的zImage启动qemu的，但是是从vmlinux加载符号的.它们是不同的:zImage基本上是vmlinux压缩为数据有效载荷，然后附加到存根，该存根将其解压缩到内存中，然后跳转到start_kernel.

You are not able to put breakpoints on any function preceding start_kernel because you are not loading symbols for them. In fact you are starting qemu with a zImage of the kernel but loading the symbols from vmlinux. They are not the same: zImage is basically vmlinux compressed as a data payload which is then attached to a stub which decompresses it in memory then jumps to start_kernel.

start_kernel是vmlinux的入口点，它前面的任何函数(包括decompress_kernel)都是存根的一部分，在vmlinux中不存在.

start_kernel is the entry point of vmlinux, any function preceding it, including decompress_kernel, are part of the stub and not present in vmlinux.

我不知道是否通过"arm-none-linux-gnueabi-gdb zImage"可以调试存根，我一直在使用JTAG调试器在真实硬件上进行ARM内核的早期调试，并且从未使用过qemu为此，对不起

I don't know if doing "arm-none-linux-gnueabi-gdb zImage" instead allows you to debug the stub, I have always done early debug of ARM kernels with JTAG debuggers on real hardware, and never used qemu for that, sorry

这篇关于在Qemu中使用GDB调试Linux内核无法达到功能或给定地址的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！