Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!cbmehq!babylon!rbabel
From: rbabel@babylon.rmt.sub.org (Ralph Babel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Starting another copy of your own code
Message-ID: <06545.AA06545@babylon.rmt.sub.org>
Date: 11 Mar 91 23:30:36 GMT
References: <63329@eerie.acsu.Buffalo.EDU> <19578@cbmvax.commodore.com> <06417.AA06417@babylon.rmt.sub.org> <18cb4d63.ARN0b56@swinjm.UUCP> <1991Mar9.170859.4810@Sandelman.OCUnix.On.Ca> <06493.AA06493@babylon.rmt.sub.org> <cg.7124@ami-cg.UUCP>
Reply-To: cbmvax.commodore.com!cbmehq!babylon!rbabel (Ralph Babel)
Lines: 33

In article <cg.7124@ami-cg.UUCP>, cg@ami-cg.UUCP (Chris
Gray) writes:

> Ralph is saying that the technique of building a SegList
> structure at run-time and then using it with CreateProc is
> self-modifying code. I won't argue the definition (I don't
> think it is, I think it is dynamically created code).

"dynamically-created code"? Chris, I guess you've been doing
too much compiler development lately! :-)

> The technique does not break on systems with caches, [...]

I think it does. Here's the scenario:

1. Process P1 executes its code in memory chunk M;
2. Parts of chunk M will be loaded into the code cache;
3. Process P1 terminates;
4. The memory area occupied by P1's code segment (including
   chunk M) is released to the free-memory pool;
5. Process P2 allocates a fake seglist; let's assume this
   seglist happens to be located in chunk M;
6. The code to be executed is copied to M, but this copying
   does _not_ update the _code_ cache!!!
7. Since CreateProc() doesn't clear the code cache, it will
   read the _old_ code from process P1 when entering the
   fake seglist.

> It is NOT because it breaks on CPUs with caches,

It does break on CPUs with _separate_ code and data caches.

Ralph