home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sun / misc / 5220 < prev    next >
Encoding:
Text File  |  1992-11-12  |  2.7 KB  |  55 lines
  1. Newsgroups: comp.sys.sun.misc
  2. Path: sparky!uunet!pipex!harlqn.co.uk!harlqn!jont
  3. From: jont@harlqn.co.uk (Jon Thackray)
  4. Subject: Register windows and non-determinacy on Sparc
  5. Message-ID: <JONT.92Nov12144657@ml.harlqn.co.uk>
  6. Lines: 44
  7. Sender: news@harlqn.co.uk (Usenet News Account)
  8. Organization: Harlequin Limited, Cambridge, England
  9. Date: Thu, 12 Nov 1992 14:46:57 GMT
  10.  
  11. I have what I think is a non-determinacy problem with Sparc register
  12. windows when running user programs on a Sun 4/330 with SunOS 4.1.1.
  13. Perhaps some kind reader of this group can help. The problem concerns
  14. values in registers which will become visible after one or more saves.
  15. The reason I am asking about this is because I have spent some time
  16. trying to use adb to track a problem in a garbage collected language
  17. implementation, and it appears that the use of adb, or perhaps just
  18. context switching actually hides the problem. The conditions are
  19. roughly as follows:-
  20. At the bottom of a sequence of procedure calls, each of which acquires
  21. a new register window via save, a bad value (as far as the garbage
  22. collector is concerned) gets put in to a register. The code then
  23. returns several stack levels and sets off down another sequence of
  24. procedure calls, eventually entering the garbage collector. The
  25. garbage collector performs two saves, and a flush_windows trap to
  26. force all register contents onto the stack so it can scan them and fix
  27. them up. One of the registers flushed onto the stack in this way is the
  28. aforementioned bad value. The problem arises if I try to use adb to
  29. stop somewhere just before the garbage collection. In this case the
  30. bad value doesn't appear on the stack when the garbage collector is
  31. entered, instead a 0 (zero) appears there. This suggests that the
  32. register values appearing when saves are done may be modified in a way
  33. which has nothing to do with the program running. Before starting the
  34. program the register windows not yet visible are cleaned using a
  35. clean_windows trap, and the same happens whenever the runtime system
  36. returns to the compiled code. Can the OS, in some asynchronous way,
  37. also clean the registers between the current window pointer and the
  38. window overflow mark? Anyone got any alternative suggestions as to
  39. what is going on?
  40.  
  41. Incidentally, I've found the source of the original problem, which was
  42. a piece of the runtime system failing to clear out a bad value it had
  43. created, I'm much more interested in knowing why adb removed the
  44. evidence whenever I tried to look at it.
  45.  
  46. Replies by email preferred, but I will scan this group as well.
  47. --
  48.  
  49. Jon Thackray                    jont@uk.co.harlqn       44 223 872522 (voice)
  50. Harlequin Ltd.                  jgt1@uk.ac.cam.phx      44 223 872519 (fax)
  51. Barrington Hall
  52. Barrington
  53. Cambridge CB2 5RG
  54. England
  55.