[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Thing crashes..
> I'm experiencing some problems with Thing v1.29 (june 20 2000) when
> running with Memory Protection enabled. Thing is killed by an illegal
> instruction, and this happens after it receives VA_PROTOCOL from
> another application it starts (like SuJi). Thing used to handle such
> problems by catching "cannot access this stuff, cause sender uses
> private mem for VA protocol stuff", and display an alert telling me.
> Did the fake super stuff and emulation of privilege instructions
> break this?
1. The fake super stuff shouldn't have influence, since all this is is
(should be) inactive, because the code is not complete (68040/60 part is
missing). All handlers begin with the line like:
if ((curproc->p_flag & P_FLAG_SUPER) == 0)
return 0;
and this condition: ((curproc->p_flag & P_FLAG_SUPER) == 0) should for now
always be true, since there is no code in the entire kernel, that would set
the P_FLAG_SUPER bit in the p_flag variable. I believe so, at least.
2. As for the move from SR instruction (this is the only privileged
instruction, that is emulated, reason the same as above), I experienced that
if this emulation is faulty, Thing refuses to run at all. One can only
wonder, what Thing desktop requires move SR,dx for, on everything except
mere 68000, but this is a fact.
The only part, that can matter, is that moves SR to memory (in user mode,
that is) are really illegal, and raise the privilege violation exception. If
this is the case, the emulation code should be fixed to verify, if the
memory belongs to the caller, etc.
I guess that only one addressing mode can do this:
move SR,(An,Dn)
The rest is either emulated, ignored, or illegal (on 68000).
--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org
** Ea natura multitudinis est,
** aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (Liwiusz XXIV, 25).