Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!stdc01!mjones
From: mjones@stdc01.UUCP (Michael Jones)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <573@stdc01.UUCP>
Date: 17 Oct 89 12:39:10 GMT
References: <1080@mipos3.intel.com> <1989Oct11.013553.3893@esegue.segue.boston.ma.us> <527@eedsp.gatech.edu>
Reply-To: mjones@stdc01.UUCP (Michael Jones)
Organization: Star Technologies, Graphicon Products Division (RTP, N.C)
Lines: 25


  In article <527@eedsp.gatech.edu> aaronb@lagrange.UUCP (Aaron Birenboim) writes:
  >johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
  >>...  Most computers fetch
  >>instructions considerably ahead of where they are executing; even the lowly
  >>8086 can fetch up to 6 bytes ahead of where it is executing.  This means that
  >>if you store into the next instruction, the CPU might or might not already
  >>have fetched that instruction, so it might execute the old instruction or ...

  >Is this really true?  There isn't enough dependancy checking in the
  >8086 instruction pipe to detect this type of operation, clear
  >the pipe, and re-fetch the altered instruction, or some such
  >corrective measure.  I'm glad I don't try self-modifying code.

It is most absolutely true. Some of the early copy protect schemes (I think it
may have been Lotus 1.0) used this sort of thing to disarm trace or single-step
breaking of their code. If you ran normally, the CPU did not see the write into
"here + 1", but if you were single stepping, or had an ICE, or whatever, then it
did. This happened several times in the code, with each false branch sending you
to a pile of "mystery code".

-- 
-- Michael T. Jones          Email:            ...!mcnc!rti!stdc01!mjones --
-- The wise man will pursue  Paper: 3101-H Aileen Drive, Raleigh NC 27606 --
-- excellence in all things  Voice: W:(919)361-3800  and  H:(919)851-7979 --