9

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 functions 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
Cœur
  • 37,241
  • 25
  • 195
  • 267
vinay hunachyal
  • 3,781
  • 2
  • 20
  • 31
  • Just wondering the function is called or not. Can you add a printk and confirm that the function is called?? – Jeyaram Apr 18 '16 at 11:01
  • @Jeyaram obviously the function should be called, as its generic function once kernel bootsup ,"Uncompressing Linux....... done, booting the kernel". this was done by decompress_kernel() function – vinay hunachyal Apr 18 '16 at 11:14
  • Agree. That's what I'm confused as well. But what happens if the kernel Image is not compressed one ?? Are you seeing "Uncompressing Linux....... done, booting the kernel" message ?? – Jeyaram Apr 18 '16 at 11:36
  • yes iam seeing the message , may be the problem is with serial console which may not be initialized well before , since putc which is the platform specific code.. i guess not sure – vinay hunachyal Apr 18 '16 at 12:08

1 Answers1

2

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

Giuseppe Gorgoglione
  • 329
  • 1
  • 4
  • Thank you, i will try this "arm-none-linux-gnueabi-gdb zImage" . Just for curiosity can i use vmlinux present in /arm/boot/compressed/vmlinux instead kernel proper (vmlinux) so that this vmlinux has eveything? – vinay hunachyal Apr 21 '16 at 12:49
  • BTW by seeing System.map address i am trying to put the breakpoint e.g Breakpoint 1 at 0x80008000: file arch/arm/kernel/head.S here without hitting this address the qemu is booting why this is so? – vinay hunachyal Apr 21 '16 at 12:52
  • 1
    No, /arm/boot/compressed/vmlinux is just an intermediate product of the compilation. It is an elf binary including symbols and relocation info, not a raw binary. You cannot boot the system with it. – Giuseppe Gorgoglione Apr 21 '16 at 13:16
  • /local/c_vhunac/vinay/Kernel_Src/Kernel/linux/arch/arm/boot/zImage": not in executable format: File format not recognized – vinay hunachyal Apr 22 '16 at 03:53
  • Yes, of course, zImage is a raw binary while gdb expects an ELF... My bad. – Giuseppe Gorgoglione Apr 22 '16 at 08:46