brownrigg@kuhub.cc.ukans.edu (12/12/90)
Summary: "...and I thought SADE was a P.P.E. (1) for a debugger..." Where does sdb come from? My first and only experience with it is with A/UX. I've never seen it on any other Unix-box I've encountered (I'm not a Unix god, and have personally experienced only 4 vendors' implementations). But if I may: I'd suggest a more appropriate name would be "msdb" - Marginal Symbolic DeBugger. Its bad enough that the thing knows fairly little about the 3G-language one might be using (as if under Unix there were a plethoria of choices): it knows nothing of typecasts; doesn't understand "*myPtr"; can't trap conditionally (that I've found); ... But by far, the worst offense has got to be a debugger that pumpkinates trying to display the contents of memory: sdb dies brutally if it tries to display a location as float/double which is not in valid form (e.g. NAN). Am I full of sh*t here? I'd like some feedback folks-in-the-know. Personally, 1) if I could garrantee valid contents of memory locations I wanted to display, I sure wouldn't need a debugger... 2) since CTRL-D is overloaded in the sense it displays the "next block of" either source text, OR memory locations, depending upon context, I'm constantly being nailed by intending to display the next 10 lines of code, after having displayed some memory contents, only to have the next <= 10 memory locations displayed and invariably one of them "ain't kosher floating point". Ka-boom! (doctor says if doing that hurts - stop doing that - thanks doc, you're a lot of help). So what's the "community" have to say about my ramblings? Rick Brownrigg Kansas Geological Survey (1) P.P.E.: Piss-Poor Excuse.
rmtodd@servalan.uucp (Richard Todd) (12/13/90)
brownrigg@kuhub.cc.ukans.edu writes: >Where does sdb come from? My first and only experience with it is with >A/UX. I've never seen it on any other Unix-box I've encountered (I'm not >a Unix god, and have personally experienced only 4 vendors' implementations). Lemme guess--most of the other Unix boxen you encountered were BSD machines, right? sdb was dreamed up by the fine folks at AT&T USG (though not exclusively found on SysV machines; it also surfaces on BSD systems that use COFF-format for their executables--there is at least one, believe it or not). Yes, sdb comes from the same crew that gave you the fixed-size tables in cc, make, and damn near everything else on SysV (apparently under the belief that everyone still has PDP-11s with 64K max data space :-). (Okay, enough USG flamage for now, you get the idea). >But if I may: I'd suggest a more appropriate name would be "msdb" - >Marginal Symbolic DeBugger. Its bad enough that the thing knows fairly Yep. About the only good thing about sdb is that it is more clueful about handling C structures et al than its predecessor adb. (I haven't personally seen all the misbehavior of sdb you report, but I'm willing to take your word on it.) However, there is relief courtesy of your friendly next-door (literally) archive site, wuarchive.wustl.edu. Lurking in the /systems/aux/ gnu directory are executables for GDB, the GNU Debugger. It does know from typecasts, groks *myPtr, has a conditional trap facility that'll blow your mind, and I haven't yet seen it core dump, and it's got a whole lot more nice features, too. Note that there are two versions of gdb on wuarchive; the one starting with "sgdb-..." is for programs compiled with cc; the one starting with "gdb-..." is for programs compiled with gcc (or g++ -- gdb has some support for C++ debugging). >1) if I could garrantee valid contents of memory locations I wanted to >display, I sure wouldn't need a debugger... 2) since CTRL-D is overloaded Heh. No kidding... >in the sense it displays the "next block of" either source text, OR memory >locations, depending upon context, I'm constantly being nailed by intending >to display the next 10 lines of code, after having displayed some memory >contents, only to have the next <= 10 memory locations displayed and >invariably one of them "ain't kosher floating point". Ka-boom! (doctor GDB has separate commands for displaying source files and displaying memory locations. >So what's the "community" have to say about my ramblings? Don't fight, switch. :-) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Try looking in the Yellow Pages under 'Psychotics'." -- Michael Santana
jk@Apple.COM (John Kullmann) (12/13/90)
In article <27409.27657285@kuhub.cc.ukans.edu> brownrigg@kuhub.cc.ukans.edu writes: >Summary: "...and I thought SADE was a P.P.E. (1) for a debugger..." > > >Where does sdb come from? My first and only experience with it is with >A/UX. I've never seen it on any other Unix-box I've encountered (I'm not SDB is a System 5 ism. Lots of UNIX systems have it. No one likes it. I suggest you use 'CDB' available from APDA or wing it and use one of the versions of GDB. Both understand source level debugging, structures and pointers, etc. I personally like CDB. Sorry about SDB, I'll flame AT&T from you (and me again) next time I talk to them! jk -- John Kullmann Manager, A/UX Product Development jk@apple.com
thad@cup.portal.com (Thad P Floryan) (12/13/90)
Y'know, as much as I maintain that VAX/VMS is truly the Vomit Making System, the one (and ONLY) thing it has going for it is its windowing debugger. Now if only someone would port that (or a clone thereof) to UNIX ... "Dear Santa, Gimme a 3-part windowing debugger for UNIX. :-) " Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
coolidge@cs.uiuc.edu (John Coolidge) (12/14/90)
rmtodd@servalan.uucp (Richard Todd) writes: >brownrigg@kuhub.cc.ukans.edu writes: >Yep. About the only good thing about sdb is that it is more clueful about >handling C structures et al than its predecessor adb. adb is still fairly useful if you want to quick-and-dirty look at a bunch of assembly, though :-) (actually, this is often something I want to do; it's useful when doing operating systems development at times :-)). >However, there is relief courtesy of your friendly next-door >(literally) archive site, wuarchive.wustl.edu. Lurking in the /systems/aux/ >gnu directory are executables for GDB, the GNU Debugger. It does know from >typecasts, groks *myPtr, has a conditional trap facility that'll blow your >mind, and I haven't yet seen it core dump, and it's got a whole lot more >nice features, too. Note that there are two versions of gdb on wuarchive; >the one starting with "sgdb-..." is for programs compiled with cc; the one >starting with "gdb-..." is for programs compiled with gcc (or g++ -- gdb has >some support for C++ debugging). Actually, there are three versions. gdb-3.5 exists in two versions: the 'gdb' version which reads dbx format debugging symbols (produced by gcc/g++ and gas) and the 'sgdb' version which reads sdb format symbols (cc/as). gdb-3.6- exists only in the dbx format; I'm unsure as to whether supporting sdb format symbols is a useful thing to do (is anyone out there actually using sgdb? Or any of the compilers that produce sdb format symbols?). I advise using gdb-3.6-, since it does a much better job of handling g++ and also doesn't coredump on files using shared libraries (and in general just seems more robust). It is pretest software, though; you should delete it in favor of 3.6 when the full release comes out (in fact, there seems to be some doubt about 3.6; some people have told me that they may go straight to 4.0). I'll be off the net for at least one and perhaps three weeks (vacation; hope to have network access in a week). Happy holidays! --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.