Date: Wed, 29 Apr 1998 13:46:39 +0800 From: Greg Lehey <grog@lemis.com> To: Peter Wemm <peter@netplex.com.au>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Michael Hancock <michaelh@cet.co.jp>, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet ip_fw.c Message-ID: <19980429134639.55598@papillon.lemis.com> In-Reply-To: <199804241534.XAA15328@spinner.netplex.com.au>; from Peter Wemm on Fri, Apr 24, 1998 at 11:34:01PM %2B0800 References: <199804241515.LAA09494@khavrinen.lcs.mit.edu> <199804241534.XAA15328@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 April 1998 at 23:34:01 +0800, Peter Wemm wrote: > Garrett Wollman wrote: >> <<On Fri, 24 Apr 1998 17:00:02 +0900 (JST), Michael Hancock <michaelh@cet.co. > jp> said: >> >>> On Fri, 24 Apr 1998, Terry Lambert wrote: >>>> That is, "ps" operates on system dumps as well as running systems. >> >> We have already determined that this mode of operation will not be >> supported in the future (right, dg?). If you want to debug a kernel >> dump, use the debugger. > > IMHO, this is fine as long as gdb gets a 'ps' command. > > What I'd love to see is a cross between gdb and the SVR4 crash(1M) command. > That would be a seriously powerful combination. > > root@gecko[5:19pm]~peter/src/startppp-116# crash > dumpfile = /dev/mem, namelist = /stand/unix, outfile = stdout >> ? > > (etc) > > Basically crash(1M) for those who've not seen it, is kinda like a > user-mode DDB but it knows how to display just about everything in detail > ranging from summary mode to huge detail. Well, I'd like the *functionality* of crash without the emetic syntax. It's high on my list of "must do if I ever find the time". The really big thing that ddb and remote gdb both don't do is show you the state of processes which aren't executing at the time. If you're debugging a multi-process scenario, this is a must (it's also pretty indispensible for debugging hangs). > So, if somebody ever had huge amounts of spare time, a combination of GDB's > source debugging, a DDB/crash(1M) style interface and a decent scripting > system would be dynamite. We could then have a reasonable chance of > putting together a sample script to do information gathering for people to > run on their crashdumps for inclusion with send-pr etc. Add in gdb-remote > and you've really got something worth yelling about. Well, I'd like to say "yes", but I promised to do it two years ago, so I don't need to promise again (and you can also gauge the likelihood of me doing it now). What I do have, though, is some code from a kernel debugger I wrote for BSD/386 about 6 years ago, before ddb and friends were available on this platform. It does some things that ddb doesn't, including hardware breakpoints (using the debugging registers). If anybody wants it, let me know. It will need at least minor interface modification to work with FreeBSD. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980429134639.55598>