MIPS simulator initializes LSI pmon vector table with code

[cgd@broadcom.com]

At Wed, 24 Apr 2002 01:24:20 +0000 (UTC), "Alexandre Oliva" wrote:
> > * 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.

Uh, not true AFAICT.

The LSIPMON handler pointers for which this might be a problem are the
ones when loop == 0 and loop == 1, right?  Since both of those are
written, really, there would be no "half halt sequences" remaining.


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

"hmm."


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

That's unfortunate.

I'd certainly be willing, as co-maintainer, to help look into the
problem.  However, my time is rather limited.

The first thing to do there is IMO probably _not_ to run the GCC
tests; you've already verified that they're borken.  It's to find out
exactly what LSIPMON is _supposed_ to be doing, and why.  (The theory
being that it's important to understand what you're trying to change,
before you go and change it.  8-) I think that's the most sane path to
a fix that's likely to work in the longer term.

Do (any of) you have pointers to documentation which will help
elucidate LSIPMON's use of 0xbfc00200?



cgd