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
Improve this question
4
  • Just wondering the function is called or not. Can you add a printk and confirm that the function is called?? Commented Apr 18, 2016 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 Commented Apr 18, 2016 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 ?? Commented Apr 18, 2016 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 Commented Apr 18, 2016 at 12:08

1 Answer 1

Reset to default
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

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

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?
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?
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.
/local/c_vhunac/vinay/Kernel_Src/Kernel/linux/arch/arm/boot/zImage": not in executable format: File format not recognized
Yes, of course, zImage is a raw binary while gdb expects an ELF... My bad.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.