home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8182 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  1.5 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!dtix!mimsy!ra!tantalus!eric
  2. From: eric@tantalus.dell.com (Eric Youngdale)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Shared Libraries Considered Harmful
  5. Message-ID: <3345@ra.nrl.navy.mil>
  6. Date: 14 Aug 92 02:31:35 GMT
  7. References: <1992Aug12.202438.19963@serval.net.wsu.edu> <1992Aug13.124928.13672@crd.ge.com> <1992Aug13.205728.25720@serval.net.wsu.edu>
  8. Sender: usenet@ra.nrl.navy.mil
  9. Organization: Naval Research Laboratory
  10. Lines: 24
  11.  
  12. In article <1992Aug13.205728.25720@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
  13. >I am not sure if you can run gdb on binaries linked with the shared libs.
  14. >Since gcc 2.2.2, if you compile foo with -g, libg.a will be used instead
  15. >of libc.a.
  16.  
  17.     You can run gdb on executables linked to the shared libs.  There are
  18. a couple of limitations, however.  If a program crashes within one of the
  19. routines in the shared library, you do not get a meaningful backtrace.
  20. As long as program control is in your program and not the shared library
  21. you can debug fairly normally.
  22.  
  23.     I also found that if I attach a running program that was linked to the
  24. sharable library, that control would often be in the sharable library, and thus
  25. I could not get a meaningful backtrace.  It is possible to set breakpoints and
  26. then let it run until it hits the breakpoint, and then you can debug fairly
  27. normally. 
  28.  
  29.     Obviously, if you are trying to debug a library routine you ought not
  30. link to the sharable library.
  31.  
  32. -Eric
  33. --
  34. Eric Youngdale
  35. eric@tantalus.nrl.navy.mil
  36.