Date: Wed, 11 Mar 1998 09:41:43 +1030 From: Greg Lehey <grog@lemis.com> To: Anatoly Vorobey <mellon@pobox.com>, hackers@FreeBSD.ORG Subject: Re: ddb Message-ID: <19980311094143.32447@freebie.lemis.com> In-Reply-To: <19980309201318.43775@techunix.technion.ac.il>; from Anatoly Vorobey on Mon, Mar 09, 1998 at 08:13:18PM %2B0200 References: <19980309201318.43775@techunix.technion.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 March 1998 at 20:13:18 +0200, Anatoly Vorobey wrote: > I was thinking of doing some work on ddb, but for all I know, > all the serious developers are doing kgdb anyhow and any changes > wouldn't be much needed ;) I don't have two FreeBSD machines > to do kgdb and I've been spoiled by good powerful debuggers, I don't > feel at home with ddb ;) Well, it would certainly be a good idea. I've been thinking of it myself, having also been used to better debuggers. > How much do you think the following would, or would not be useful? > (from easier to harder). > > 1. More convenient symbols support, e.g. "sym nfs*" to list all > symbols starting from nfs/_nfs with their values. I don't see the need for this. I've found symbol completion with tab to be completely adequate, and easier to use. > 2. Encapsulation of traps on entry/exit; i.e. you can't panic by > trying to read nonexistent page in ddb, Definitely. The fact that ddb can cause traps is a bug. > you can list nonexistent pages and see '???' values on them. No, it should tell you that the page doesn't exist. > 3. Independence from syscons, and ability to be brought up on > just about hardest crashes, when syscons goes down too. At some point you need to negotiate with syscons. I once write a debugger for BSD/386 which used separate I/O. You can have the code if you want, but it's (deliberately) pretty primitive. > 3.5. A printf-style routine directing to the debugger to print on > its terminal; unlike tprintf/uprintf/kvprintf and friends, > blocking and guaranteed to print everything no matter how often > called. (maybe there's such a beast already and I missed it? pray tell). Maybe I'm misunderstanding the background here. What's the problem with kvprintf? > 4. Intel-style asm listing (yeah, right, flame away). It would be nice to use Intel mnemonics, so that at least you could refer to the Intel literature, but until the whole system has changed, it would just confuse things. I vote against. > 5. Source-level listing, by having a userland loader program give > sources you're interested in to ddb; ddb would keep them in locked > memory (no pagefaults, debug vm manager). My BSD/386 debugger did this, but it was a real kludge. It wouldn't be much of a basis. > 5. Better integration with the kernel; i.e. change address spaces > inside ddb, That's the big one. I want to be able to analyse hangs, and at the moment I can't because I'm either not in a process environment, or in the wrong one. > intelligent display of important structures (mbuf, buffer, iostruct, > whatever). Well, if it reads in the kernel symbol table, it'll know *all* the structs. kgdb can display them. It would be nice to have ddb (or replacement) do so as well. Of course, all these things would require a ridiculous amount of locked memory--maybe as much as 32 MB. A debug kernel alone is about 10 MB. For many applications, this usage would be warranted, but it would make sense to cater for installing only partial sources, and removing them when you're done. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980311094143.32447>