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

问题描述

以下是我的设置： -

在一个终端运行

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

在其他终端

  arm-none-linux-gnueabi-gdb vmlinux 
从vmlinux读取符号...完成。 
（gdb）target remote：1234 
远程调试使用：1234 
 0x60000000在?? （）
  

我的问题是/ arch / arm / boot /压缩/ *文件

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

案例1：

 （gdb）b decompress_kernel 
函数decompress_kernel未定义。 
在将来的共享库加载时使断点挂起？ （y或[n]）y 
断点2（decompress_kernel）待处理。 
（gdb）c 
持续。 
  

上面的一个是不能打到qemu正在启动的功能。

案例2：

 （gdb）b * 0x80008000 
断点1在0x80008000：文件arch / arm / kernel / head.S，第89行
（gdb）c 
继续。 
  

在这种情况下，它不能打，而qemu正在启动。

案例3：

 （gdb）b start_kernel 
断点1在0x8064d8d8：文件init / main.c，行498. 
（gdb）c 
继续。 
 
断点1，init / main.c中的start_kernel（）：498 
 498 {
（gdb）
  

在这种情况下，功能正在进行，我可以逐步调试。

注意：我启用了调试，早期printk和尝试hbreak

所以我的查询是

  1 ）为什么一些功能不能打破点？ 
 2）这是qemu限制还是需要启用更多的东西？ 
 3）我需要附加任何额外的参数吗？ 
 4）如何调试早期内核启动
  

解决方案

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

start_kernel是vmlinux的入口点，它之前的任何函数，包括decompress_kernel，都是存根的一部分，不存在于vmlinux中。

我不知道是否做arm-none -linux-gnueabi-gdb zImage代替允许你调试存根，我一直在实际硬件上使用JTAG调试器对ARM内核进行早期的调试，从来没有用过qemu，对不起，

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

Below is my setting:-

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

In other terminal

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

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

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

Case 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.

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

Case 2:

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

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

Case 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.

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

So my query is

 1)why some funtions are not able to hit break points?
 2)Is this qemu limitation or do i need enable something more ?
 3)do i need to append any extra parameters ?
 4)how to Debug early kernel booting 

解决方案

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 is the entry point of vmlinux, any function preceding it, including decompress_kernel, are part of the stub and not present in vmlinux.

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屋！