From owner-freebsd-hackers Tue Nov 9 13:37:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id B4BE514A2A for ; Tue, 9 Nov 1999 13:37:37 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id NAA35735; Tue, 9 Nov 1999 13:36:56 -0800 (PST) From: Archie Cobbs Message-Id: <199911092136.NAA35735@bubba.whistle.com> Subject: Re: How to use gdb to catch a panic In-Reply-To: from Zhihui Zhang at "Nov 9, 1999 09:49:43 am" To: zzhang@cs.binghamton.edu (Zhihui Zhang) Date: Tue, 9 Nov 1999 13:36:56 -0800 (PST) Cc: grog@lemis.com (Greg Lehey), freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Zhihui Zhang writes: > Thanks for your reply. What confuses me is that when I use commands "gdb" > (enter remote protocol mode) and "step" on the target machine, the > debugging machine takes control (it executes "target remote /dev/cuaa1"). > In this case, how can I run anything on the target machine to trigger a > panic? I'm not sure if this answers your question, but the command sysctl -w debug.cebugger=1 will cause the kernel to stop and return your gdb prompt. Then you could call the function panic() directly if you wanted. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message