Any successful story of debugging linux 4.13 with qemu 2.10 and gdb 8.01?
mudongliangabcd at gmail.com
Wed Sep 20 11:20:12 EDT 2017
2017-09-20 4:18 GMT-04:00 jjDaNiMoTh <jjdanimoth at gmail.com>:
> Hello all,
> As the title says, any of you have successfully tried to debug Linux
> 4.13 with QEMU? My problem is that it is not possible to break (even
> with hbreak) in any function of the kernel, from the most used
> (schedule or spin_lock) to the most obvious (uptime_proc_show when
> /proc/uptime is read).
> To be more specific, QEMU correctly stops if I put "-s -S" on the
> command line, and perfectly continue the execution of the kernel when
> I connect gdb using 'target remote :1234'. However, any breakpoint is
> simply ignored.
I encountered this problem in my debian testing. Any "break" or
"hbreak" point is not triggered
even if I set breakpoint at "start_kernel".
The version of those software are as follows :
qemu 1:2.8+dfsg-7 amd64
gdb 7.12-6 amd64
kernel 4.13.0 (build by myself)
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:
I try to use busybox and one simple "helloworld" rootfs. The result
shows it is not related with rootfs.
It seems gdb does not handle register length of amd64 due to
But until now, I did not figure out the reason why this error occurs
and how to fix it.
My best regards to you.
No System Is Safe!
> I have followed any possible tutorial and any possible answer to
> similar user questions. I also tried to do the same on a 16.04 version
> of Ubuntu, but the result is always the same. In particular, I have
> using both a busybox image and a raw filesystem image of Archlinux.
> There is any known problem in debugging Linux? How can I "debug" this
> debug process?
> Thank you!
> Stay open, be free.
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
More information about the Kernelnewbies