2017-09-20 15:29 GMT-04:00 jjDaNiMoTh <jjdanimoth@gmail.com>:
On 20/09/17 at 11:20am, 慕冬亮 wrote:
2017-09-20 4:18 GMT-04:00 jjDaNiMoTh <jjdanimoth@gmail.com>:
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!
JJD
[1] https://www.google.com/search?q=packet+reply+too+long+gdb+linux