On Thu, 8 Jul 1999, Wolfgang Solfrank wrote:

> The problematic places are the signal trampoline code (which is written
> out by the MI code via copyout) and any code that is handled via
> vmcmd_map_readvn (expecially small programs which are linked -N).
> The former could be handled in the MD sendsig routine (albeit no port
> seems to do this either), but I can't see how the latter should be
> handled. (Since, at least on ELF, binaries linked -N didn't work until
> yesterday anyway, this problem probably didn't arise before).
> 
> Comments?

  It looks to me like vmcmd_map_readvn() is calling uvm_map_protect()
after the data has been read into memory.  Presumably that is setting the
page back to read-only using pmap_protect(), which the m68k ports will
clear the caches for the 68040 and 68060 when the protection is being
changed to read-only.  The mips3 systems do have a problem with this,
which causes gdb to fail on the R4x00 systems.

  I'm not sure about the signal trampoline code - it does seem to work on
the 68040/68060 and MIPS R4x00 systems.  I don't have a clear
understanding of exactly how that works, so I don't know how the caches
would affect that.  I think the trampoline code is written to the user
stack only when the process starts, and is only executed after that to
deliver the signal.  On the 68040, something must be forcing the data
cache to be written to memory at some point so the instruction fetch gets
the valid contents.  I can't think of anything that explicitly does that
at the moment.

Michael

---
Michael L. Hitch			osymh@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA