CODEWITHSUNDEEP
debugginglinux-kernelremote-debugging
anupamD
anupamD

Reputation: 952

Question mark symbols in gdb while debugging linux kernel 4.10

I am trying to debug the linux kernel right from the function start_kernel() in the linux kernel.

This is basically what I ve done

Downloaded the kernel source for 4.10 from kernel.org After extracting the source:

make menuconfig : Changed the settings for kernel debugging

make -j4: compiled the kernel

Simply issued the command without any FS

qemu-system-x86_64 -kernel linux-4.10/arch/x86/boot/bzImage -append root=/dev/zero -s -S The qemu stoped as it should:

Next in another terminal, i started gdb

gdb vmlinux : and the output is as follows

... ...

Reading symbols from vmlinux...done.

(gdb) target remote :1234 Remote debugging using :1234 0x0000fff0 in ??() (gdb) list

1   /*
2    *
3    *  Copyright (C) 1991, 1992  Linus Torvalds
4    *
5    *  Enhanced CPU detection and feature setting code by Mike Jagdis
6    *  and Martin Mares, November 1997.
7    */
8   
9   .text
10  #include <linux/threads.h>

That means debug symbols are there. Now when i use the command

(gdb) b start_kernel

Breakpoint 1 at 0xc1ba986e: file init/main.c, line 483.

And I hit c (continue), it doesn't hit the breakpoint.

What wrong am I doing?

Thanks

Upvotes: 0

Views: 730

Answers (2)

river
river

Reputation: 734

Try to disable CONFIG_DEBUG_RODATA and CONFIG_RANDOMIZE_BASE.

Upvotes: 0

WAmBerS
WAmBerS

Reputation: 314

You should use hardware breakpoints instead of software breakpoints.

You can use hbreak to insert hardware breakpoints. hbreak and break have similar usages. Moreover, you can use help hbreak to show more information.

I guess that the reason why software breakpoints are not effective is that the INT3 instruction inserted by software breakpoints is covered when the kernel image is loaded after you continue the QEMU.

But some troubles will occur because the processor mode changes. This gives some useful answers.

Upvotes: 0

Related Questions