Remote gdb debugging does not stop at breakpoints

Question

I'm having problems with debugging my modified Linux-3.11.0 kernel. For debugging the code, I use:

1. GDB 7.6
2. QEMU 1.6.5
3. Linux kernel 3.11.0

My system has Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz running Ubuntu 12.10

I compiled the modified kernel with a configuration file that I created using 'make menuconfig'. (with modifications in the "kernel hacking" category)

Some of the .config file lines (that I find relevant) are quoted here:

CONFIG_DEBUG_INFO=y 
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y

I use qemu with the "-S" option to boot my kernel, and using gdb I connect to qemu and resume it's execution:

(gdb) target remote :1234
(gdb) continue

When setting breakpoints, for an example: break schedule I get a confirmation message such as:

Breakpoint 1 at 0xffffffff81736400: file kernel/sched/core.c, line 2509.

So till here everything seems fine!

The problem is that gdb and qemu does not stop at the breakpoints! They both simply continue running...

I tried to set hardware breakpoints as suggested in some places, but I get the message:

No hardware breakpoint support in the target.

which is weird because I have the CONFIG_HAVE_HW_BREAKPOINT set.

I also unset CONFIG_DEBUG_RODATA as suggested in other places,but still no results...

I tried to mess around with the .config file as suggested here: gdbserver inside qemu does not stop on breakpoints but I couldn't figure out the relevant differences between the working .config file and my .config file... (There are too much differences!)

Can anyone please help me?

Thank You!!

Answer 1

OK, I found the problem so I'm posting here for other people: Apparently this is a very delicate procedure... My config file was fine. All I needed to do is to define the breakpoints only after I connect to qemu, and not after loading the vmlinux. These breakpoints have to be HARDWARE breakpoints... otherwise they don't break!

Answer 2

Mis-matched symbols also lead this issue. eg: you are loading symbols from host-side vmlinux, which is NOT identical to the debuggee.