Re: MIPS simulator initializes LSI pmon vector table with code

[cgd at broadcom dot com]

At 22 Apr 2002 16:08:54 -0300, Alexandre Oliva wrote:
> I asked fche, and he agreed my fix was reasonable, so I checked it in,
> just to have it reverted by one of the maintainers, and then have the
> other maintainers say I should have done exactly what I did :-(

Well, what I was suggesting was meant to be a prefix for "and then
submit it via normal channels" which you didn't do.  8-)


> > If you go back to the original code in public rev 1.1, what you'll
> > find is that the writes of 'halt' to the BFC addrs above was done
> > _before_ the pmon/lsipmon loop to write the values.
> 
> Except that there was no pmon/lsipmon in rev 1.1.  Only idtmon.

Excuse me?

There were no variables to control use of the blocks of code, but the
blocks of code were there and run unconditionally, unless i'm going
blind...

lines 529 - 605 of rev 1.1, or thereabouts.


> According to a comment in the code, that was already in rev 1.1:
> 
>       /* The PMON monitor uses the same address space, but rather than
>          branching into it the address of a routine is loaded. We can
>          cheat for the moment, and direct the PMON routine to IDT style
>          instructions within the monitor space. This relies on the IDT
>          monitor not using the locations from 0xBFC00500 onwards as its
>          entry points.*/
> 
> Clearly, if pmon (and lsipmon) expect the address of the handler to be
> written into that space, writing a HALT instruction will get you the
> wrong effect.  Since AFAICT that range is only used by the lsipmon, I
> propose that, instead of just `#if'ing out that code, we actually
> remove it.

So, go through and look at what the code does:

* the PMON support _does not_ uses the memory at 0xbfc00200, except for
the halt instructions.  its handler address ptrs go at 0xbfc00500.

* lsipmon puts the handler addresses at 0xbfc00200.  If the handler
address setup were run after the halt code init, I believe that would
have the right effect.


I still don't believe you explained if there's anything special about
the LSI MiniRISC parts that makes that 'OK' or 'normal'.  On most MIPS
parts, like I said, those will be the TLB handlers.  (You're
apparently using it, which is why you care about this patch; surely
you can say what it's trying to do!  8-)

If the MiniRISC doesn't have a TLB, that would probably explain it
(but i'd like to know for sure, and it should probably be mentioned in
a comment).

Regardless, if that's what the monitor does, that's what the monitor
does, and that should be supported, but not at the expense of ripping
the 'halt's out for other monitors (which is what you did).


> > The action that the 'halt'-writing code accomplishes is that it
> > arranges to halt the simulator when you get one of these exceptions.
> 
> Nope, it arranges for an invalid instruction to be executed, or a
> branch to an invalid address to be taken, if you get the monitor
> conventions wrong.

That's what the _bug_, for your particular monitor, causes.  I believe
what I stated _is_ the goal of the halt-writing code.  8-)


> The right thing to do is to not write code into the table if it's not
> supposed to contain code.

So,

(1) It's fairly obvious that for other monitors that location _should_
    contain code.

(2) you've not explained why the lsipmon monitor _doesn't_ contain
    code there, at a location where the MIPS architecture says
    _should_ contain executable code.

(3) If you do the halt-writing first, followed by the pmon/lsipmon
    vector init (as revision 1.1 of the file did), I _believe_ all
    would be OK.


I think you have more than enough information to know how fix the
problem properly, at this point.

(I'd still like to know why lsipmon thinks it's OK to put
other-than-code at that vector.)


chris