home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8920 < prev    next >
Encoding:
Internet Message Format  |  1992-08-16  |  2.7 KB
  1. Xref: sparky comp.arch:8920 comp.lang.c:12392
  2. Newsgroups: comp.arch,comp.lang.c
  3. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!mips!apple!news.oc.com!convex!ssimmons
  4. From: ssimmons@convex.com (Steve Simmons)
  5. Subject: >>>>>>>>>  What would you like in a debugger?
  6. Sender: usenet@news.eng.convex.com (news access account)
  7. Message-ID: <ssimmons.713987445@convex.convex.com>
  8. Date: Sun, 16 Aug 1992 17:50:45 GMT
  9. Nntp-Posting-Host: pixel.convex.com
  10. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  11. X-Disclaimer: This message was written by a user at CONVEX Computer
  12.               Corp. The opinions expressed are those of the user and
  13.               not necessarily those of CONVEX.
  14. Lines: 44
  15.  
  16. > 
  17. > There are several more important problems that need to be solved
  18. > first.  I'll be happy to define some way for debuggers to talk to
  19. > each other across machines once I find one or two that do what I
  20. > want on a single machine.  To be absolutely frank, the current
  21. > state of debugging "technology" is little short of abysmal.  I
  22. > don't use any debugger at the present time on UNIX systems because
  23. > I haven't found a single good one.  I don't care whether the debugger
  24. > displays linked lists nicely in an X environment.  This (without
  25. > fail) means that the programmers have concentrated on the GUI to
  26. > the detriment of the basic functionality of the debugger.
  27. > 
  28. > Seeing as nobody else has written a debugger that I'm happy with,
  29. > I'm designing one myself.  To be frank, I was somewhat disappointed
  30. > with many of the responses to my original question; people seem to
  31. > be more worried about the number of widgets they can twiddle than
  32. > whether their debuggers help them trace problems efficiently.
  33. >
  34. >        -- Bryan
  35.  
  36. Bryan:
  37.  
  38. You are definitely a true developer ... You ask people their opinions...
  39. None of them agree with yours and so you go out and reinvent the 
  40. wheel. ;-) 
  41.  
  42. I've followed the thread here.  Most people have suggested key requirements
  43. within a debugger. In fact, most of them are mundane and have been
  44. implemented in one form (or another) in "a" debugger.   The problem 
  45. is that no one debugger provides it all.  
  46.  
  47. My advice is the following... Start with the source for one debugger... 
  48. (maybe gdb or dbx).  Then, rewrite the code to do you what you think is 
  49. right.   I can guarantee two things.  Some people will love it and some
  50. people will hate it.  We wrote ours from scratch and it took 6-8 people 
  51. over one year to do it.   Personally, we probably made a mistake in 
  52. this tactic although we were limited by GNU's copyright.  Also, we 
  53. spent much time dealing with issues of optimized code debugging. 
  54. Good luck from one CXdb developer (Convex's debugger). 
  55.  
  56. Thank you. 
  57.  
  58.  
  59.                     Steve Simmons 
  60.