home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / gnu / gdb / bug / 911 < prev    next >
Encoding:
Text File  |  1992-07-28  |  1.4 KB  |  36 lines
  1. Newsgroups: gnu.gdb.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!ips.CS.tu-bs.DE!neitzel
  3. From: neitzel@ips.CS.tu-bs.DE (Martin Neitzel)
  4. Subject: Re: Execution trace feature for gdb
  5. Message-ID: <1992Jul28.114950.3647@ips.cs.tu-bs.de>
  6. Summary: It's not sooo easy...
  7. Sender: gnulists@ai.mit.edu
  8. Organization: Inst. f. Informatik, TU Braunschweig, FRG
  9. References: <9207201607.AA02430@bugs.airs.com>
  10. Distribution: gnu
  11. Date: Tue, 28 Jul 1992 11:49:50 GMT
  12. Approved: bug-gdb@prep.ai.mit.edu
  13. Lines: 21
  14.  
  15. I just asked the same question about the "trace facility in the dbx
  16. sense" three months ago and digged into the gdb source.
  17.  
  18. I found out that this functionality would require more than, say, a
  19. twenty line patch.  The framework for integrating "trace points" as
  20. another variant of break and watchpoints points is there.  The new
  21. "trace" commands set would nicely fit into it (arguments/syntax just
  22. like "break" commands with lots of code reuse possible).  I'd estimate
  23. that modifications would mainly concern about three modules.
  24.  
  25. But at that time, I was just too busy with my regular work(*) to
  26. figure out how to distribute the trace marks into the code (for a
  27. "trace function fred" command).  I felt not being expert enough to
  28. assess viability/quality my own idea for an implementation and didn't
  29. any further work on it.  (A broad, two page overview about gdb's inner
  30. concepts and workings would have been very helpful at that point.)
  31.  
  32.                         Martin Neitzel
  33.  
  34. (*) Still am, sorry.
  35.  
  36.