From owner-freebsd-hackers Fri Mar 14 12:53:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA11360 for hackers-outgoing; Fri, 14 Mar 1997 12:53:01 -0800 (PST) Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11351 for ; Fri, 14 Mar 1997 12:52:49 -0800 (PST) Received: from chai.plexuscom.com (localhost.torrentnet.com [127.0.0.1]) by chai.plexuscom.com (8.8.5/8.8.5) with ESMTP id PAA00554 for ; Fri, 14 Mar 1997 15:53:12 -0500 (EST) Message-Id: <199703142053.PAA00554@chai.plexuscom.com> To: hackers@freebsd.org Subject: kernel remote debugging using gdb Date: Fri, 14 Mar 1997 15:53:12 -0500 From: Bakul Shah Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This seems to work mostly but there are a few problems. What I did: - recompiled the boot program to always use COM1 as console and installed it on the primary disk on the test machine (called TEST). - used the following options in the TEST config file: options COMCONSOLE options DDB options BREAK_TO_DEBUGGER - config -g TEST and compiled the test kernel on the development machine (called DEVEL), and copied it to TEST. - connected TEST's COM1 to DEVEL's COM2 with a `null modem' cable. - started kermit on DEVEL and connected to TEST @ 9600 baud - rebooted TEST. When the boot prompt came up in the kermit window, booted the kernel single-user. - once the kernel came up I hit ^\b in kermit to send a break to TEST. When DDB gained control I typed gdb so that on the next trap it will start the gdb remote protocol. I continued the kernel and then I sent another break and the TEST kernel did spew out out gdb remote stuff (which has a distinctive pattern). - Next I stopped kermit on DEVEL and chdir'ed to $SRC/sys/compile/TEST and started gdb. - in gdb I typed file kernel target remote /dev/cuaa1 At this point gdb starts controlling the remote kernel. Now one can add breakpoints, examine variables and so on. There are two problems: - Sendind a break in multiuser mode (before or after attaching gdb) does not seem to drop the kernel in the debugger. This seems to work occasionally but I haven't as yet figured out under what conditions. - In single user mode when gdb is attached, you can not type anything on the console nor can you see any printf() output[1]. These problems make debugging the kernel with gdb somewhat challenging. Am I doing something wrong or missing a crucial step? If these problems can be solved may be the above description can be added to the handbook or the FAQ. I am debugging a 2.2-961006-SNAP, if it matters. Thanks for any help! Any other hints/ideas on making this process less tedious are also more than welcome. -- bakul [1] Note that passing console device IO `through gdb' would be extremely useful as it will feel as if gdb is built in. Not sure if this works at all for the standard gdb remote protocol. At any rate adding it would not be hard.