home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / sys5 / r4 / 911 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.1 KB  |  46 lines
  1. Newsgroups: comp.unix.sys5.r4
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!rfg
  3. From: rfg@netcom.com (Ronald F. Guilmette)
  4. Subject: Debugging C code on SVR4 (was: cc -g problem)
  5. Message-ID: <1992Dec21.092236.21804@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. Date: Mon, 21 Dec 1992 09:22:36 GMT
  8. Lines: 36
  9.  
  10. Some time ago, georg@norisc.erls01.siemens.de (Georg Biehler) wrote:
  11.  
  12. > The bug is in cc,  it produces wrong (or missing) line number information
  13. > for compilation units including files with functions defined in there.
  14. > An example is <sys/stat.h>,  defining stat(),  lstat() and other variants
  15. > or <sys/uname.h>.
  16. > 
  17. > The bug is in generix UNIX SVR4,  even in 4.2.  A (ugly) workaround is
  18. > to include the complete include file in your source file - this makes you
  19. > able to debug the code.
  20.  
  21. There does indeed seem to be a bug in the production of the DWARF line
  22. number information in generic (unfixed) versions of the standard SVR4
  23. C compiler.  This bug can be *very* annoying, and can make effective
  24. debugging almost impossible (as you are never really sure where you
  25. actually are).
  26.  
  27. Fortunately, the GNU C compiler does not suffer from this problem.  The
  28. DWARF line number information which it produces is correct (as far as
  29. I have been able to determine) and the DWARF output from GCC is 100%
  30. compatible with the standard SVR4 sdb debugger.  In fact, there are a
  31. few additional obscure cases where the DWARF output produced by GCC
  32. will cause the SVR4 sdb debugger to give answers which are *MORE CORRECT*
  33. than they would be if the same code had been compiled by the standard
  34. SVR4 C compiler.
  35.  
  36. -- 
  37.  
  38. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  39. //
  40. //      "On the one hand I knew that programs could have a compelling
  41. //       and deep logical beauty, on the other hand I was forced to
  42. //       admit that most programs are presented in a way fit for
  43. //       mechanical execution, but even if of any beauty at all,
  44. //       totally unfit for human appreciation."
  45. //                                              -- Edsger W. Dijkstra
  46.