Date: Thu, 27 Dec 2007 10:20:14 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/ddb db_command.c db_command.h db_lex.c db_lex.h db_main.c db_script.c ddb.h Message-ID: <20071227101217.P59006@fledge.watson.org> In-Reply-To: <4772E8F4.3080908@elischer.org> References: <200712260933.lBQ9XJi7039100@repoman.freebsd.org> <20071226181850.GA6300@green.homeunix.org> <20071226233301.K59006@fledge.watson.org> <4772E8F4.3080908@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Dec 2007, Julian Elischer wrote: >> Thanks! DDB capture output, scripting, and textdumps were pretty much what >> I had in the queue for DDB at this point. I'll see if I can't come up with >> some stuff, and look forward to hearing about how people use these ones. >> I'll also happily accept bug reports... >> >> Textdumps should open up the door for some interesting things in terms of >> bug management--I'd love to see someone put together some rc.d/rc.conf >> parts to do automated crash report submission (disabled by default, of >> course) and a database to hold the results. I suspect a moderate number of >> panic reports are lost on the basis that filing a proper bug report is >> fairly difficult (get out kgdb, etc), or that the boxes quietly reboot and >> the core dumps rot on disk (to be deleted when space runs out). Perhaps >> hoovering up those textdumps, especially if we can correlate them with one >> another using some automated processing, might be quite informative. Or >> just a good time sink :-). > > scripting is made almost infinitly more useful with some > registers/variables.. > > (especially if there is some simple looping.. allowing following of a linked > list or similar.) For the purposes of textdumps, the current simple scripting pretty much met my needs. One of the interesting advantages to DDB is its very domain-specificity: because it's intended to debug only one program, the kernel, it has a lot of commands that are quite aware of kernel semantics. As a result, unlike with a traditional general-purpose debugger, you don't need an extensive script language to report on data structures, the keeping of invariants, etc, because there is a trivial facility to add new commands to inspect data. For the purposes of scripting debugging at breakpoints for something other than basic reporting, and for teaching the scripting language how to manage data structures, you'd need something significantly more complex. To do much more with scripting than I've done would probably require a fairly major restructuring of DDB. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071227101217.P59006>