From owner-freebsd-smp Thu Feb 28 17:34:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 1880237B417 for ; Thu, 28 Feb 2002 17:33:49 -0800 (PST) Received: (qmail 30633 invoked from network); 1 Mar 2002 01:33:40 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.152.157]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Mar 2002 01:33:40 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g211XHG42450; Thu, 28 Feb 2002 20:33:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3.0.6.32.20020228184845.00da5868@imatowns.com> Date: Thu, 28 Feb 2002 20:33:10 -0500 (EST) From: John Baldwin To: Glenn Gombert Subject: Re: Some thoughts on Giant instrumentation Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 28-Feb-02 Glenn Gombert wrote: > > > First a 're-cap' of the various kernel-debugging resources that are > available and then a couple of suggestions from my own (somewhat limited) > experience… > > There are basically four different types of kernel debugging 'schemes' > that can be configured with what is commonly available in -Current: > > (1). Kernel debugging can be done (from user space) using the gdb > debugging (gdb -k kernelxxx) which can be used to do such simple things as > examine/set global variables,etc. > > (2). A serial console can be set up (using a remote machine) using the ddb > debugger, and a kernel compiled on the host machine which had the 'Options > ddb' and associated 'break_to_debugger' options enabled in the kernel. > > (3). The third is a option to remote (over serial line(s)) perform remote > kernel debugging using a 'stripped' kernel booted on a second machine and > running ddb/gdb from two serial consoles on the second (debugging) machine. > > (4). The fourth option is to use a VMware virtual machine (running under > Current) and use it (as described on the list here at various times) to do > a versions of 'gdb debugging'. In my experience this arrangement is very > slow but does have the advantage of using only on pc for as a development > platform. > > I think what needs to be added (and is sorely lacking) are some good > syscalls (that can be called from 'userland' to perform such things as dump > out the 'ktr' buffer from a user land program and show contents of some of > the other kernel parameters (when using a test program from user land). It > seems like a good set of 'debug syscalls' would be a good addition to the > smp code that is -current and would make debugging/development efforts > easier and more efficient for everyone :)) Yep, being able to dump ktr to userland would be rather cool indeed if you'd like to tackle it. :) > Glenn Gombert > ggombert@imatowns.com > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message