[vmips] Instructions emulated?

[Brian R. Gaeke]

Hi,

I'm going to squish all my responses to your past couple of emails
together...

And then spake Cable Guy, as follows:
> Thanks for the info.  My VMIPS only gets to the point where it issues
> the "afraid of the dark" message and then hangs.  I built gdb-insight
> from the 6.1 sources to help debug this puppy, but gdb-insight wants
> an input program when you start it and there are 2 input programs
> here.  I can load boot.exe into it _or_ vmlinux, not both, so it has
> been a bit frustrating tracing the interaction.

Oftentimes it's better to just load vmlinux into gdb, on the theory
that most of your execution time will be spent in vmlinux. I agree that
this is a huge shortcoming. I haven't got a better solution at present,
though I have some ideas...gdb just isn't designed to debug across
multiple address spaces and symbol tables at the same time.

> When it hangs it encouters a SIGEMT trap with $pc = 0x80040080

Sorry, I don't know what a SIGEMT is.  The vmips->gdb interface only
works with signal numbers, and sadly, different OSes give signals
different names.

> (vmlinux load address 0x80040000) and cause = 0x1c.  Not sure what

vmips/cpzeroreg.h has a listing of what the different bits in the Cause
register mean.

> I saw the patch you submitted the
> other day, Brian, so I'll bear that in mind when I build it.

Apparently it isn't needed for real DECstations, but you will need it for
VMIPS.

> As a followup to my own post I think the SIGEMT actually gets vectored
> to the 0x8000000 region when BEV = 0.

Yes, that'd make sense. It'd be important to try and figure out what is going
on to cause the exception. Since you said it occurs right at the beginning of
execution, maybe you could just set a breakpoint at 0x80040000 and trace
through the first 40 or 50 instructions? It sounds like something is
going wrong right at the beginning of execution.

> I don't think it does, but can you confirm there's no VMIPS support
> for the instructions "ll" and "sc"? 

Yes, there's no "ll"/"sc" support in VMIPS, because although "ll" and "sc"
are fine instructions, VMIPS is an R3000 simulator, and the R3000 didn't have
them.

> I'm having a devil of a time building my own toolchain since GCC,
> at least through the 3.2.x series, won't generate mips1 code without
> them, even when -march=r3000 and/or -mips1 is specified.  I found
> this thread...  http://gcc.gnu.org/ml/gcc/2002-06/msg01189.html
> ... which pre-dates GCC 3.2 and the behavior still hasn't been fixed
> satisfactorally in over 2 years.

What can I say, that's a gcc bug... My suggestion is: don't build a
C++ compiler and don't build libstdc++, from which the broken assembly
language stems. Configure gcc with --enable-languages=c. I currently do
that for my mipsel-linux toolchain, which is gcc-3.3.2. Or, you could
use gcc-3.0.x; I use it quite a bit for regression testing (although
not for building Linux kernels) and it suits me fine, although I've
never bothered with the C++ compiler.

>  After spending several days building
> and re-building cross-compilers for MIPS for gcc 3.2, 3.2.1, 3.2.2 and
> 3.2.3 I'm starting to think the answer is to modify VMIPS instead to
> handle these instructions.  The cpu I want to emulate - the MIPS 4kc -
> does implement the "ll" and "sc" instructions so I think that is probably
> the best way to go if I ever hope to run or debug code for my router.

That's also a reasonable way to go. Full support for the rest of the MIPS32
instruction set has been "on my list" for a while, but I haven't had time.
If you do extend the CPU, I'd love to take your patch!

Let me know if you have other questions.
-Brian

-- 
Brian R. Gaeke, brg at dgate.org -- GnuPG encrypted mail gleefully accepted