Any successful story of debugging linux 4.13 with qemu 2.10 and gdb 8.01?

慕冬亮 mudongliangabcd at
Thu Sep 21 13:08:18 EDT 2017

2017-09-20 15:29 GMT-04:00 jjDaNiMoTh <jjdanimoth at>:
> On 20/09/17 at 11:20am, 慕冬亮 wrote:
>> 2017-09-20 4:18 GMT-04:00 jjDaNiMoTh <jjdanimoth at>:
>> > Hello all,
>> >
>> > As the title says, any of you have successfully tried to debug Linux
>> > 4.13 with QEMU?
>> I encountered this problem in my debian testing. Any "break" or
>> "hbreak" point is not triggered
>> even if I set breakpoint at "start_kernel".
> [cut]
> So, after two weeks of a headache I took the courage to send an email
> here, and after only 3 hours after the email (!!!) I found the cause of
> the problem.
> Without being too long, the problem is KALSR. You have to disable it
> disabling the kernel option "Randomize the address of the kernel image (KASLR)",
> inside Processor type and features. In this way, gdb can translate
> all the symbols correctly (symbols <-> addresses).
> I really don't know how the developers test their code... because there
> is no evidence for this.
>> But I found one interesting phenomenon:
>> If you try to "Ctrl + C" to stop the gdb when you see busybox is
>> already working, you will see one special error:
>> Remote 'g' packet reply is too long:
> [cut]
> The answer to this issue is found easily on the internet. You have to
> stop using -S, because it creates problems. Please take a look to [1].

I have seen this solution during searching answers. But without "-S"
(-S stalls QEMU CPU at startup), the kernel will not stop util it reaches
busybox command line.
In other word, you have no method to debug the Linux early boot process.

So I try to find solution to fix it and debug the kernel from
start_kernel to review
the early boot process of linux Kernel.

I do not know how one senior developer debugs kernel code. I just want to
use qemu, gdb to debug and learn how kernel works.

> Thanks for your reply and have a nice day!
> [1]

More information about the Kernelnewbies mailing list