Date: Thu, 28 Feb 2002 20:33:10 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Glenn Gombert <ggombert@imatowns.com> Cc: smp@FreeBSD.org Subject: Re: Some thoughts on Giant instrumentation Message-ID: <XFMail.020228203310.jhb@FreeBSD.org> In-Reply-To: <3.0.6.32.20020228184845.00da5868@imatowns.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020228203310.jhb>