home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / intel / 1499 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  1.3 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!wupost!gumby!yale!mintaka.lcs.mit.edu!ai-lab!zurich.ai.mit.edu!jinx
  2. From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
  3. Newsgroups: comp.sys.intel
  4. Subject: Re: 386 <-> 486 incompatibilities
  5. Message-ID: <JINX.92Aug13224100@chamarti.ai.mit.edu>
  6. Date: 14 Aug 92 02:41:00 GMT
  7. References: <16ds34INNpvn@fbi-news.Informatik.Uni-Dortmund.DE>
  8.     <1992Aug13.232325.930@colorado.edu>
  9. Sender: news@ai.mit.edu
  10. Reply-To: jinx@zurich.ai.mit.edu
  11. Organization: M.I.T. Artificial Intelligence Lab.
  12. Lines: 18
  13. In-reply-to: drew@ophelia.cs.colorado.edu's message of 13 Aug 92 23:23:25 GMT
  14.  
  15. In article <1992Aug13.232325.930@colorado.edu> drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
  16.  
  17. |   >-Is there a way to detect this kind of self-modification
  18. |   > either at runtime (say, with a small TSR debugger-like program) or 
  19. |   > scanning the assembly-code sources.
  20. |
  21. |   Scanning the assembly code should do it.
  22. |
  23.  
  24. That is not completely true.  A program that dynamically creates and
  25. executes code can create and execute code that modifies itself within
  26. the prefetch buffer, even though the original did not.
  27.  
  28. Both the Gambit and MIT Scheme compilers (and others as well) have had
  29. to deal with this problem in the past, and in no case was the code
  30. apparent from looking at the sources, since it was dynamically created
  31. and executed code.
  32.  
  33.