Date: Mon, 9 Mar 1998 20:13:18 +0200 From: Anatoly Vorobey <mellon@pobox.com> To: hackers@FreeBSD.ORG Subject: ddb Message-ID: <19980309201318.43775@techunix.technion.ac.il>
next in thread | raw e-mail | index | archive | help
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 ;) 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. 2. Encapsulation of traps on entry/exit; i.e. you can't panic by trying to read nonexistent page in ddb, you can list nonexistent pages and see '???' values on them. 3. Independence from syscons, and ability to be brought up on just about hardest crashes, when syscons goes down too. 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). 4. Intel-style asm listing (yeah, right, flame away). 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). 5. Better integration with the kernel; i.e. change address spaces inside ddb, intelligent display of important structures (mbuf, buffer, iostruct, whatever). Suggestions and flames are welcome. -- 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?19980309201318.43775>