home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / linux / 25215 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  3.1 KB
  1. Path: sparky!uunet!pipex!warwick!uknet!edcastle!dcs.ed.ac.uk!sct
  2. From: sct@dcs.ed.ac.uk (Stephen Tweedie)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Missing stuff: pstat, tset, NIS?
  5. Message-ID: <SCT.93Jan23162304@ascrib.dcs.ed.ac.uk>
  6. Date: 23 Jan 93 16:23:04 GMT
  7. References: <C16J5A.9Lw@news2.cis.umn.edu> <1993Jan21.124216.13521@aston.ac.uk>
  8. Sender: cnews@dcs.ed.ac.uk (UseNet News Admin)
  9. Organization: University of Edinburgh Dept. of Computer Science, Scotland
  10. Lines: 55
  11. In-Reply-To: evansmp@uhura.aston.ac.uk's message of 21 Jan 93 12:42:16 GMT
  12.  
  13. In article <1993Jan21.124216.13521@aston.ac.uk>, evansmp@uhura.aston.ac.uk (Mark Evans) writes:
  14. > : >In article <lma.727207214@dayton.Stanford.EDU>, lma@dayton.Stanford.EDU (Larry Augustin) writes:
  15. > : >
  16. > : >Pstat?  Nope.  Anyway, the kernel structures have been changing too
  17. > : >rapidly to make such a beast easy to maintain...
  18.  
  19. > The current idea appears to be to impliment examination of any
  20. > kernel data structures by using the /proc filesystem.  The format of
  21. > this is likely to be more stable (once all the bits have been put
  22. > in) than diging arround in /dev/kmen i.e. no recompiling
  23. > tools/rebuilding databases whenever the kernel is changed!
  24.  
  25. /dev/kmem or some form of explicit system support (via syscalls or
  26. /proc) is needed to allow programs access to internal data structures,
  27. but for human browsing of kernel space, there is another way...
  28.  
  29. The dead easy way of looking through the kernel: if you are running a
  30. kernel with all of the object files still kicking around in the
  31. correct places, then you can use GDB to look at the kernel while it is
  32. running!  (Although obviously you can't change actually change
  33. anything.  That would be just TOO dirty.)
  34.  
  35. The program file to run GDB on will usually be
  36. /usr/src/linux/tools/system.  But the clever bit is that GDB will
  37. allow you to debug a program on a core dump file, and linux is cunning
  38. enough to be able to present the running kernel image to GDB as a
  39. core-dump image!
  40.  
  41. The trick is to create a /dev/core character device with major/minor
  42. 1,6 (ie. mknod /dev/core c 1 6).  Then
  43.     gdb /usr/src/linux/tools/system /dev/core
  44. and you're away!
  45.  
  46. I understand that the procedure is especially useful if you have
  47. compiled tools/system with the -g flag, but I have only tried it out
  48. on a non-debugging kernel.  However, it works wonderfully.
  49.  
  50. By the way, it is a good idea to be pretty careful about the
  51. permissions you set on /dev/core if you are at all worried about
  52. security...
  53.  
  54. Oh, and another point.  If you get a kernel panic, it is a great idea
  55. to run GDB on tools/system and "disassemble 0x<offending-pc>" (where
  56. offending-pc is the program counter reported in the kernel panic
  57. message.  GDB will automatically work out the enclosing function
  58. (well, at least narrowing down to the surrounding global symbols if
  59. the kernel is compiled without -g), so you have a good chance of
  60. locating fairly precisely the offending code.  This can make tracking
  61. down kernel bugs a LOT easier.
  62.  
  63. Cheers,
  64.  Stephen Tweedie.
  65. ---
  66. Stephen Tweedie <sct@uk.ac.ed.dcs>   (Internet: <sct@dcs.ed.ac.uk>)
  67. Department of Computer Science, Edinburgh University, Scotland.
  68.