Debugging a Linux kernel using GDB in qemu, unable to call a function or a given address

Question

I am trying to understand the kernel boot sequence step by step using GDB in qemu.

Below are my settings:

In one terminal I run

~/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 another 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 to set a breakpoint for the code in the / arch / arm / boot / compress / * files.

For example, I tried to set a breakpoint for depress_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 cannot use the qemu download function.

Case 2:

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

In this case, it also cannot click, instead, QEMU boots.

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, the function works, and I can debug it step by step.

Note: I turned on debugging, early printing and tried hbreak

So my query is:

1. why some functions cannot get to breakpoints?
2. Is this a limitation of QEMU or do I need to include something more?
3. Do I need to add any additional parameters?
4. how to debug early kernel loading

Answer 1

You cannot set breakpoints on any function preceding start_kernel because you are not loading characters for them. In fact, you start qemu with the zImage kernel, but you load characters from vmlinux. They do not match: zImage is basically vmlinux compressed as useful data information, which is then attached to a stub, which unpacks it in memory, and then goes to start_kernel.

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

I don’t know if "arm-none-linux-gnueabi-gdb zImage" instead allows debugging a stub, I always did early debugging of ARM cores with JTAG debuggers on real hardware and never used qemu for this, sorry