Date: Wed, 11 Mar 1998 18:20:53 +0200 From: Anatoly Vorobey <mellon@pobox.com> To: Greg Lehey <grog@lemis.com> Cc: hackers@FreeBSD.ORG Subject: Re: ddb Message-ID: <19980311182053.65072@techunix.technion.ac.il> In-Reply-To: <19980311094143.32447@freebie.lemis.com>; from Greg Lehey on Wed, Mar 11, 1998 at 09:41:43AM %2B1030 References: <19980309201318.43775@techunix.technion.ac.il> <19980311094143.32447@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
You, Greg Lehey, were spotted writing this on Wed, Mar 11, 1998 at 09:41:43AM +1030: > > 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. I'm somewhat unclear yet on hierarchy issues. Such a change would definitely be i386-dependent; and sys/ddb seems to be architecture-neutral on purpose. Where does this change belong then? > > 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. Why? You can do your own I/O pretty easily, w/ saving/restoring current syscons' virtual screen and trapping keyboard. Of course, that, too, would be very pc-centric. > > 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? It uses syscons and appears to be nonblocking. If you kvprintf in a place which is called very often, you lose output or parts of it (happened to me all the time as I inserted tprintf's in NFS code). > > 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. What about an option? > > 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. Another very desirable feature is breakpoints conditioned on virtual space (i.e. break on nfs_write() in syncer process only). Of course, full-featured conditional breakpoints would be even better... > > 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. Does the usual -g in compiler flags insert structs layout as well? > Of course, all these things would require a ridiculous amount of > locked memory--maybe as much as 32 MB. Why? I disagree. The symbol table is already there in the kernel image, and you don't have to copy all of it. Unless you want to bring ALL the /sys into locked memory, you can do well with 1-2Mb of locked memory reserved for sources, which is how much sources you usually deal with during a single debug anyway. > 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. Exactly. -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton 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?19980311182053.65072>