Debugging Linux Kernel using GDB in qemu unable to

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:

why some functions are not able to hit break points?
Is this qemu limitation or do I need enable something more?
do I need to append any extra parameters?
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