bengsig@oracle.nl (Bjorn Engsig) (09/28/90)
[Please continue in comp.unix.programmer. ] Article <2460@ns-mx.uiowa.edu> by bonak@herky.cs.uiowa.edu (Esmail Bonakdarian) says: |I am trying to decide which debugger to learn to use with C on |our BSD Unix system. | |What are the relative merits of the sdb and dbx programs? If you have dbx, use that. The syntax and semantics of sdb are so strangely interwoven that it is a pain. E.g: 'xyz' prints the value of xyz, 'i' issues the i command even if there is an i variable. -- Bjorn Engsig, Domain: bengsig@oracle.nl, bengsig@oracle.com Path: uunet!mcsun!orcenl!bengsig From IBM: auschs!ibmaus!cs.utexas.edu!uunet!oracle!bengsig
scc@rlgvax.UUCP (Stephen Carlson) (10/02/90)
In article <998@nlsun1.oracle.nl> bengsig@oracle.nl (Bjorn Engsig) writes: >If you have dbx, use that. The syntax and semantics of sdb are so strangely >interwoven that it is a pain. E.g: 'xyz' prints the value of xyz, 'i' issues >the i command even if there is an i variable. Two things you could do for sdb: 1) Use 'i/' to print the value of 'i'; after being bitten a few times (especially with a variable named 'c'), you learn your lesson. Just like the old C problem: if (a = b) ... 2) Use 'ii' instead of 'i'. Searching for the variable 'i' in most editors is a royal pain. The vi locution \<i\> is almost as annoying to type as it is to have the simple search confound the 'i' variable with, say, the 'if' and the 'while' keywords. Searching for 'ii' will not have either problem. On my system, dbx has a fatal flaw: it does not exist. But given a choice, since sdb has a higher learning curve than most debuggers (except for adb), I wouldn't endorse it. -- Stephen Carlson | ICL OFFICEPOWER Center scc@rlgvax.opcr.icl.com | 11490 Commerce Park Drive ..!uunet!rlgvax!scc | Reston, VA 22091
mday@iconsys.uucp (Matt Day) (10/05/90)
Since nobody has done so already, I must recommend GDB as the debugger of choice. GDB supports nearly all the features found in both adb and sdb with extensions to provide a command-line history, user-definable aliases, and many more handy little things that we all cherish, not to mention the fact that it's free, portable to many systems, and I've noticed that it's quite a bit faster than sdb (don't know about adb). Note: you don't have to use GCC to debug your programs with GDB, GDB understands standard object file formats on most systems (but you really should use GCC; plug, plug). They can all be downloaded from prep.ai.mit.edu:pub/gnu (18.71.0.38). -- - Matthew T. Day, Sanyo/Icon, mday@iconsys.icon.com || uunet!iconsys!mday
lee@sq.sq.com (Liam R. E. Quin) (10/13/90)
bengsig@oracle.nl (Bjorn Engsig) writes: > If you have dbx, use that. The syntax and semantics of sdb are so strangely > interwoven that it is a pain. [...] S'true... although System V 3.2 sdb has a lot more features these days. I use Saber-C by preference, but it isn't exactly free... Anything that implements run-time array bounds and malloc- checking is a big win, at least for me. Oh, and that detects when you use a variable before setting it. In the absence of Saber, I either cry [:-)] or use dbx/sdb/adb in that order. If gdb is around it's worth looking at around the same time as you investigate dbx. Other good things include writing a wrapper round malloc() that checks that youdon't free the same thing twice, etc.... some versions of malloc() will do that for you if you can persuade them. Oh, and get to like lint! Lee -- Liam R. E. Quin, lee@sq.com, SoftQuad Inc., Toronto, +1 (416) 963-8337