home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5301 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.2 KB  |  57 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!venice!gumby.dsd.trw.com!eel.dsd.trw.com!gottloeb
  3. From: gottloeb@eel.dsd.trw.com (Jeffrey R. Gottloeb)
  4. Subject: Re: GDB under 386bsd 0.1
  5. Message-ID: <1992Sep8.163904.8941@gumby.dsd.trw.com>
  6. Keywords: gdb, ptrace
  7. Sender: news@gumby.dsd.trw.com
  8. Organization: TRW, INC.
  9. References: <1992Sep4.005417.3876@gumby.dsd.trw.com> <1992Sep4.153554.4387@cs.few.eur.nl>
  10. Date: Tue, 8 Sep 1992 16:39:04 GMT
  11. Lines: 44
  12.  
  13. In article <1992Sep4.153554.4387@cs.few.eur.nl> pk@cs.eur.nl writes:
  14. >In <1992Sep4.005417.3876@gumby.dsd.trw.com> gottloeb@eel.dsd.trw.com writes:
  15. >
  16. >>I have noticed a problem using gdb under 386bsd 0.1.
  17. >
  18. >>When at least one breakpoint has been set and the program terminates,
  19. >>e.g. executes exit(), the breakpoint is not removed from the process's
  20. >>text image.  When the program is subsequently re-executed under gdb,
  21. >>gdb remembers that a breakpoint is supposed to at the memory location
  22. >>and puts one there again.  However this time it shadows the breakpoint
  23. >>instruction from the previous run rather than the original instruction.
  24. >>When execution begins after reaching the breakpoint, various traps occur.
  25. >
  26. >>If the program is run after quitting gdb, a Trace/BPT trap occurs.
  27. >
  28. >>I think the problem is that gdb assumes that when ptrace modifies the
  29. >>process's image the kernel either makes a private copy of the text image
  30. >>or it will throw away the text image after the process terminates.
  31. >>However, this is not the case - the kernel keeps the modified text image
  32. >>around and executes it rather than a fresh copy from the original file.
  33. >
  34. >The 386 does not generate a page protection fault while it is executing
  35. >in supervisor mode :-(, so copy on write handling never takes place when
  36. >the kernel stuffs data into a process's text- or any other non-anonymous
  37. >segment. So these cases must be explicitly checked for. Here's a patch
  38. >for kern/sys_process.c:
  39. >
  40. >
  41.  
  42.       (code deleted)
  43.  
  44. >
  45. >I am not entirely happy about the call to `vm_fault', but at this moment 
  46. >I don't see another way to enforce a copy on write.
  47. >
  48. >-pk
  49.  
  50.  
  51. I modified kern/sys_process.c with the patch and rebuilt the kernel.
  52. This fixed the problem.  Thanks.
  53.  
  54.  
  55. Jeff Gottloeb
  56. gottloeb@gumby.dsd.trw.com
  57.