Hi,

>   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.

Hmm, thanks for the hint.  However, this means that running programs
linked -N wouldn't work, as these have their code mapped writable.

But then again, until my patch done yesterday, at least some -N binaries
(like a "main(){}") wouldn't have worked anyway.

>   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.

This is probably the result of doing a lot of things before catching the
first signal and thus flushing the icache.  Try the regress/kern/sigtramp
test, it should most likely fail on these architectures (albeit one can't
be sure as it depends on the exact layout of the code in the resulting
executable).

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800