🚀 go-pugleaf

 In a previous article, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>In article <14827@netcom.UUCP> mcmahan@netcom.UUCP (Dave Mc Mahan) writes:
>> In a previous article, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>>>Again that old theme '(self) modifying code': When I think about it,
>>>there HAS to be a clean way. How else could a debugger or a machine
>>
>>2.  The second method used works only with debug code in RAM.  The debugger is
>>    instructed by the user to replace the instruction at the desired address
>>    with an illegal instruction (usually, the ILLEGAL instruction itself!  This
>>    is a real op-code, haveing a value of 0x8AFC.  Look it up!)
>
>Stop. Here you again poke simply two bytes into RAM and hope they will
>get executed. But in the days of (separate) data and instruction caches
>you can't be sure that the CPU will see this!

Yes, it is possible for your program to write to memory and have the write stay
in the cache instead of actually getting flushed into memory, or to have the
instruction cache already loaded with the instruction location you replaced and
have it execute from the cache version rather than the modified version.  Now
that cache machines are upon us, this fact has to be remembered by the person
writing the debugger.  The only method I can think of that would work is to
write the desired (illegal) instruction and then flush the cache into memory
to guarantee that it exists, and then to dump the entire instruction cache and
force the CPU to re-read data from main memory when it is about to execute
an instruction.  Note that this does not mean the CPU has to read data from
main memory all the time, just the first time, as it will read in the modified
instruction code and store it in the cache.  The other option is to disable
caching entirely, and force the CPU to read each instruction from memory all
the time.  This method may not work if the program being debugged decides to
enable the cache as part of the sequence of instructions it is to perform.
You are correct in assuming that LoadSeg() MUST be able to write bytes of
data into memory and then execute them as instructions, but I think that it
just flushes the data cache when it is finished writing the segment being
loaded, and then marks the entire instruction cache as being 'no good' so
that all instructions are re-read when they are initially required by the
CPU execution unit.  Although Commodore only officially supports LoadSeg()
as the means of loading data into memory, programmers who write debuggers
must bend the rules slightly (and be willing to support future modifications)
to properly do certain things on a CPU with caches.

>So again, the only official method to bring executable code into
>memory and execute it there is to LoadSeg() it. So this function
>must be the BIG exception that is capable of some magic trick to
>circumvent this cache problem under any circumstance.
>Simple question: How?

It just flushes the data cache and marks the instruction cache as being
empty when it is finished as described above.  Please remember that other
functions that pass messages back and forth between seperate CPUs working
off the same main memory must also ensure that any writing they do that
needs to be shared is also flushed.  Message passing within a one-CPU system
won't have this problem, since such a message is always treated as data.


>2nd question: If we know this trick, would it be also applyable
>for our own hacks/monitors/code generators?

I'm not sure how applicable the technique is for hacks or code generators, but
for a debug monitor that allows placing breakpoints, I can think of no other
way to perform the job except to flush caches.


>Best regards, Dr. Peter Kittel

     -dave