From owner-freebsd-questions@FreeBSD.ORG Fri Jan 2 08:51:41 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB91C1065672; Fri, 2 Jan 2009 08:51:41 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 884F38FC08; Fri, 2 Jan 2009 08:51:41 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 8F5A35B05; Fri, 2 Jan 2009 00:46:09 -0800 (PST) To: "Pranav Peshwe" In-reply-to: Your message of "Fri, 02 Jan 2009 12:40:08 +0530." References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> Comments: In-reply-to "Pranav Peshwe" message dated "Fri, 02 Jan 2009 12:40:08 +0530." Date: Fri, 02 Jan 2009 00:46:09 -0800 From: Bakul Shah Message-Id: <20090102084609.8F5A35B05@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org, shilp.kamal@yahoo.com, freebsd-questions@freebsd.org Subject: Re: FreeBSD kernel Debugging tools for Virtual Memory Module X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 08:51:42 -0000 > ddb and kgdb are two useful and often indispensable tools for kernel > debugging on FBSD. ddb won't allow you source level debugging, kgdb will, > but you'll need an extra machine. If the code you are debugging doesn't depend on specific hardware, one option is to run FreeBSD (with the kernel being debugged) under qemu and run kgdb on the host FreeBSD. Something like In Window1 $ qemu -s freebsd-disk-img ... In Window2 $ cd $ kgdb kernel.debug (gdb) target remote localhost:1234 (gdb) detach Ending remote debugging. (gdb) q $ Note: I have not tried this recently but it should work. > AFAIK, if you are modifying the kernel source directly there is no option > but to recompile all the changed and dependent files. Well... there used to be a debugger called ups with a builtin C interpreter. It allowed you to add code at run time. This was quite handy when you wanted to temporarily patch things up and continue debugging or set conditional breakpoints or insert assertion verification code on the fly. The C interpreter is worth adding to gdb but I am not sure if any of ups code can be reused. See http://ups.sourceforge.net/