home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8897 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.2 KB
  1. Xref: sparky comp.arch:8897 comp.lang.c:12306 comp.programming:2303 comp.unix.programmer:4290
  2. Newsgroups: comp.arch,comp.lang.c,comp.programming,comp.unix.programmer
  3. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!ficc!peter
  4. From: peter@ferranti.com (Peter da Silva)
  5. Subject: Re: Summary of responses [was: What would you like from a debugger?]
  6. Message-ID: <id.SKBS.RIL@ferranti.com>
  7. Keywords: summary,debugging
  8. Organization: Xenix Support, FICC
  9. References: <bosullvn.713613694@unix1.tcd.ie>
  10. Date: Thu, 13 Aug 1992 15:24:31 GMT
  11. Lines: 63
  12.  
  13. In article <bosullvn.713613694@unix1.tcd.ie> bosullvn@unix1.tcd.ie (Bryan O'Sullivan) writes:
  14. > I haven't decided yet what constitutes the smallest
  15. > debugger I can get away with, but such things as printing data
  16. > structures and their contents on the fly are out of the question.
  17.  
  18. Embed an interpreted language in the debugger (drive it from TCL?).
  19.  
  20. Then write a program to generate a routine for printing a structure based on
  21. the structure contents, and bind it to a data type.
  22.  
  23. Stick these in a file so the debugger can find them on demand.
  24.  
  25. This is sort of like "ctags": you don't have the editor grubbing through a
  26. bunch of files every time you want to find a tag. It's also a more useful and
  27. general tool than having too many smarts hardcoded into the debugger.
  28.  
  29. If you drive the debugger from TCL, someone else can write the object browser
  30. in TK.
  31.  
  32. I don't think I want the debugger command language to be C. C isn't really
  33. well suited to the job. Actually, I'd kind of like a Postscript type language,
  34. but then I'm a Forth nut.
  35.  
  36. As for finding C source, I'd like a couple of related features:
  37.  
  38.     1. An interactive mode, where if it can't find a file it asks
  39.        you where it is.
  40.  
  41.     2. A tags file, containing the location of functions, that you
  42.        can build with an external tool.
  43.  
  44. In fact, having an option that puts you into an editor on the tags file
  45. when it can't find a source file would be a good thing.
  46.  
  47. A TCL autoload file could be used for this and for the structure display
  48. stuff, above.
  49.  
  50. > 1) a programmable interface - the human debugger should be able to
  51. >    write some debugger script for things such as step-by-step every C
  52. >    instruction until such condition". The debugger language should
  53. >    absolutely be programmable. Perhaps a public domain small lisp
  54. >    interpreter -such as Emacs lisp or Xlisp- is a good starting point.
  55.  
  56. That would also be good... though I think TCL is a better command language
  57. than Lisp, Lisp tends to be faster. The biggest problem with lisp is the
  58. baroque set of basic routines.
  59.  
  60. >    The window interface to the debugger should also be programmable.
  61.  
  62. TK? WINTERP?
  63.  
  64. > Ok.  I'd like a complete programming environment as a debugger (say in
  65. > scheme or tcl or something).
  66.  
  67. Another vote for a command language!
  68.  
  69. Of course if you design an API for the debugger and it's clean enough this
  70. would become a peice of cake. DON'T forget callbacks on breakpoints!
  71. -- 
  72. Peter da Silva                                               `-_-'
  73. $ EDIT/TECO LOVE                                              'U` 
  74. %TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
  75. Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
  76.