Date: Mon, 25 Mar 96 16:41:37 MET From: Greg Lehey <lehey.pad@sni.de> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: lehey.pad@sni.de, pst@Shockwave.COM, hackers@freebsd.org, bde@freebsd.org Subject: Re: kgdb / remote gdb of the kernel? Message-ID: <199603251544.QAA20473@nixpbe.pdb.sni.de> In-Reply-To: <27135.827768356@time.cdrom.com>; from "Jordan K. Hubbard" at Mar 25, 96 7:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> I'm planning to rework kernel debugging in about a month's time. If >>>> you have any opinions about what should go in, please let me know. In >>>> particular, do you want debugging over Ethernet? >>> >>> gdb-remote! gdb-remote! >> >> Serial or Ethernet? > > Serial. I'm not aware of any IP based method of talking to a remote > gdb, I don't know of anything involving gdb, but when I was with Tandem about 5 years ago, they had something similar for the Integrity series. > and frankly I'm not even sure how it would work while > single-stepping a kernel - getting a packet off the wire and > delivering it to a usermode process takes quite a few steps, after > all, and you'd probably be left with a rather difficult debugging > scenario! :-) Yes, I had my doubts, too, but at least one manufacturer has managed it, and the question isn't "is it easy", but rather "is it desirable"? One obvious approach would be to leave interrupts enabled but change all the vectors on entering the debugger, such that most interrupts get ignored, and the ethernet interrupt goes to a special, stripped-down driver. Note also that the remote debug interface is in the kernel, and not a user process. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603251544.QAA20473>