How to Use Kgdb Over Ethernet (Kgdboe)

How to use kgdb over ethernet (kgdboe)?

Have you read this:
https://www.kernel.org/pub/linux/kernel/people/jwessel/kgdb/ch03s04.html
?

You have to run debugged kernel with special options - like for example:

kgdbwait kgdbcon kgdboe=@192.168.248.76/,@192.168.242.24/00:11:22:33:44:55

and on debugging side you run following commands:

gdb
file vmlinux
target remote udp:192.168.248.76:6443

it has worked for me.

How to debug Linux Kernel on a remote machine?

You cannot connect to a literally remote machine through a serial port. What you want to use is KGDB Over Ethernet (kdgboe). See How to use kgdb over ethernet (kgdboe)?

How to use kgdb on ARM??

Finally Host to Target communication established just bcos of line delay. There is no relationship between kernel source in development machine and time-out issues.

For the time-out kind of issue for some of the commands say qOffset and qSupported is solved by using GtkTerm instead of minicom as the serial port communication tool.
Difference is "line delay" option in GtkTerm. so when this is configured to ~250, there is no timeout message thereafter. simply connection established and waits at default break point. If anyone knows how to give this "line delay" in minicom will be more helpful to everyone.

yes ofcourse, we need source code for list command to execute. but without those source also, we can debug i.e si, bt can be executed with the help of vmlinux and system.map.

Note:: set debug remote 1 is not necessary. This gives detailed display of host to command communications. For more detailed view, set debug serial 1.

Help with a cryptic error message with KGDB - Bogus trace status reply from target: E22

If you cleared all breakpoints on the target and "C"ontinued from the latest breakpoint (assuming that the target code didn't crash, etc.), I think you'll be safe: when running, kgdb won't be talking to your gdb anyway, since if I recall, it only handles the link when stopped (in a breakpoint or exception) awaiting for commands.
A few Ctrl-C in a fast sequence if needed to get control back in gdb, then "q", and that's it.

That's at least my experience when debugging ko's...

I suspect gdb is saying this because it doesn't realize that it is talking to a kgdb rather than to a remote gdb server. I don't imagine kgdb accepting to kill a kernel thread because the debugger was exited, anyway!

Hmmm, afterthought:
You're talking about kgdb 'lite', the one now part of the kernel tree, are you? Because that's the only one I have experience with...

PS on June, 3:

I had never seen the exact message you mentioned until I moved to the 2.6.32 kernel (as part of the migration of my dev and target machines to Lucid). And then, surprise, I ran into it too. Here, it seems to happen in hopeless situations (like a segfault or kgbd seemingly running away after missing a breakpoint or single step). The only cure I have found so far was to pkill ddd (gdb) on the dev machine and reboot the target. But the good news is that the kgdb in 2.6.32 seems to be quite more stable than the one in Karmic (2.6.31).

---

Related Topics