gumby@Cygnus.COM (David Vinayak Wallace) (07/12/90)
Date: 11 Jul 90 16:53:02 GMT From: doug@dept.csci.unt.edu (Douglas Scott) Other than the bundled gdb, are there any other debuggers available for C code? Things such as lint (is there a glint??). I *sorely* miss lint! Have you tried the -Wall option to the C compiler? No, it ain't lint, but it enables warning on almost anything that might trip you up. And, umm, you know, the compiler is free software...YOU could adapt the front end to be an ansi lint... How about something like dbx -- gdb is ok, but not nearly as clever IMHO as dbx... I'm curious -- what's missing? IMAO gdb is more clever; most likely we're each missing out on the strengths of the other's fave debugger. It looks like the upcoming version of gdb will have a dbx front-end. However the NeXT gdb is pretty far out of the mainstream (understandably -- they had to add all the mach support `n stuff) so I doubt it would drop in easily. If I remember, the version NeXT forked off with predates the hairy command processing. C'mon, a graphics-based machine with no graphics debugger? Really!
dcarpent@sjuphil.uucp (D. Carpenter) (07/12/90)
In article <1990Jul11.165302.4186@dept.csci.unt.edu> doug@dept.csci.unt.edu (Douglas Scott) writes: >Other than the bundled gdb, are there any other debuggers available for C >code? According to the Suummer 1990 edition of the NeXT "Software and Peripherals" catalogue, there is a new symbolic debugger on the way, from ONyX Systems, 2325 Clareton Drive, Arlington, TX 76018 (817- 468-2695), available in fourth quarter of 90 for $295. It's called "BugByte 1.0". It's based on gdb, so I'm not sure if it will be what you want, but it might be worth checking out. -- =============================================================== David Carpenter dcarpent@sjuphil.UUCP St. Joseph's University dcarpent@sjuphil.sju.edu Philadelphia, PA 19131
bbenson@sun.com (Brent Benson) (07/13/90)
In article <1990Jul11.165302.4186@dept.csci.unt.edu> doug@dept.csci.unt.edu (Douglas Scott) writes: # # How #about something like dbx -- gdb is ok, but not nearly as clever IMHO as dbx... #besides, I run X on my machine as well, and it would be GREAT to be able to #run xdbx. C'mon, a graphics-based machine with no graphics debugger? Am I #missing something? I love my machine, but hate ascii debuggers. # I too would love to have a GUI front end for gdb on the NeXT. While I've been happy with performance of gdb, it would be great to be able to point and click to select variables and set breakpoints. Also it would be nice to have separate windows for the source, for typing commands into, and displaying variables (like dbxtool and other debugging environments). This would make developing programs on the NeXT even more fun that it already is :-). Brent -- _ _ | | __ __ __ _| |_ Brent Benson bbenson@sun.com | .\| _\/._\| \|_ _| Sun Microsystems ...sun!cashew!benson |__/|_| \__/|_|_| |_| <standard disclaimer..I'm just an intern anyway>
lane@sumex-aim.stanford.edu (Christopher Lane) (07/13/90)
In <GUMBY.90Jul11194203@Cygnus.COM>, gumby@cygnus.com writes: > ... > Have you tried the -Wall option to the C compiler? No, it ain't lint, > but it enables warning on almost anything that might trip you up. We use the following 'csh' script, stored as '/usr/local/bin/lint' (a variant of which I posted long ago as an alias): #! /bin/csh set program = $0 cc -Wall -D$program:t -S -o /dev/null ${argv[1-]} unset program This runs 'cc' with no output and skips the assembly process--useful for a quick syntax check between edits. You can also pass it other 'cc' arguments (eg -I to affect where it finds include directories). And, assuming you call it 'lint', constructs like '#ifndef lint' in code should work right. But, it isn't the same as having 'real' lint, I still occasionally sneak over to the SparcStation to 'lint' (non-Objective) C code that I'm working on. - Christopher -------
jacob@gore.com (Jacob Gore) (07/13/90)
/ comp.sys.next / bbenson@sun.com (Brent Benson) / Jul 12, 1990 / > I too would love to have a GUI front end for gdb on the NeXT. While > I've been happy with performance of gdb, it would be great to be able > to point and click to select variables and set breakpoints. Also it > would be nice to have separate windows for the source, for typing > commands into, and displaying variables (like dbxtool and other > debugging environments). While you're waiting for the GUI, you can do some of this in gdb mode in Emacs. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
dennis@bailey.cpac.washington.edu (Dennis Gentry) (07/18/90)
Reply-To: doug@dept.csci.unt.edu (Douglas Scott) How about something like dbx -- gdb is ok, but not nearly as clever IMHO as dbx... ,besides... In what way is gdb not nearly as clever as dbx? As far as I have been able to tell, gdb is far more clever than dbx. Has dbx improved substantially since I switched to gdb a year or so ago? Thanks, Dennis (dennis@cs.washington.edu)
doug@dept.csci.unt.edu (Douglas Scott) (07/18/90)
In article <DENNIS.90Jul17125628@bailey.cpac.washington.edu> dennis@bailey.cpac.washington.edu (Dennis Gentry) writes: > >In what way is gdb not nearly as clever as dbx? As far as I >have been able to tell, gdb is far more clever than dbx. Has >dbx improved substantially since I switched to gdb a year or so >ago? Two things, mainly. Dbx allows you to stop a program when the value of any variable or register changes, thereby making certain kinds of debugging MUCH easier. Also dbx allows automatic printing of the values of a number of variables, I think. At least... The graphic version, xdbx, does. This was my main point. I run X on my Cube, and if I had dbx I could run xdbx. If there were a native GUI debugger on the Cube, I would not bother with the X version. Someone out there mentioned a debugger in association with emacs...any more details on that? -- ___________________________________________________________________________ Douglas Scott doug@dept.csci.unt.edu
jacob@gore.com (Jacob Gore) (07/19/90)
/ comp.sys.next / doug@dept.csci.unt.edu (Douglas Scott) / Jul 18, 1990 / > Someone out there mentioned a debugger in association with emacs...any more > details on that? Just type "M-x gdb", and you'll be prompted for the binary. You can have the sources in one window and the gdb session in another. The current line in the source file's window (a regular, editable buffer) will have a "=>" hovering over it. There are several keys defined that speed up debugging. In gdb mode, see "C-h m" for details. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob