Re: MIPS simulator initializes LSI pmon vector table with code

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr 22, 2002, cgd@broadcom.com wrote:

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

Point taken; I think I have already apologized for crossing the line.
If I didn't, please accept my apologies.  If I did, please accept them
again :-)

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

Sorry, I looked only at the diff between 1.1 and 1.2, and I admit I
must be confused.

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

Except that some handlers would be incorrectly set with remnants of
half halt sequences.

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

Now I have to confess that I have absolutely no idea of what's going
on in there, and that I had never heard of these monitors before.  All
I know is that I was debugging some totally unrelated code for a
lsipmon toolchain, and it was crashing at the end.  I eventually
figured out that statement was overwriting the entry for the `write'
service that had been put there in the previous loop, and figured the
`???' comment just before the code meant it was wrong.

In my book, failing to halt on invocation of unregistered services in
certain configurations is much better than failing to run any program
at all on other configurations, so I came up with this patch, ran it
through Frank that agreed it looked reasonable and put it in as, well,
obvious (having no background on the issue and seeing how it was
obviously doing the wrong thing, it didn't occur to me that there
might be more to it that it seemed at first).

Anyway, I don't have sufficient knowledge nor interest in these
matters to remain in this discussion (in fact, my slow response time
can be attributed to the fact that I don't read gdb-patches very
often, I'm significantly behind on it, and I'm not sure when I'm going
to have time to even think about catching up on it :-)

I suggest the maintainers of this simulator to build a mips-lsi-elf
toolchain and attempt to run `make check-gcc' with the simulator to
duplicate the problem I had run into, and investigate more closely
what the correct fix would be.

Thanks,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer