Re: mips sim syscall

["Chris Demetriou" <cgd@google.com>]

Oooh, for once a question I can help answer!  Let me warn you, my
knowledge of this subject is pretty old, but looking at the code it
looks good enough.

On Thu, Jun 5, 2008 at 23:20, Masao Uebayashi <uebayasi@gmail.com> wrote:
> Does GDB MIPS simulator support system call emulation?  If I read code
> (sim/mips/interp.c) correctly, if SystemCall or Trap is triggered, it
> just looks at the exception vector and execute (emulate) that code.
> This won't work for *nix like environment, right?

The MIPS sim does have syscall emulation, yes.

As you note, it typically vectors exceptions as described by the MIPS
architecture.  One glaring exception is the handling of
"RSVD_INSTRUCTION", a reserved opcode (really, family of opcodes) used
by the simulator to provide system call emulation.  (In the MIPS sim,
this is *not* done using the MIPS syscall instruction.)  For this
path, look for RSVD_INSTRUCTION in signal_exception.  That code sends
the requested operation off to sim_monitor, which provides emulation
for the appropriate syscall.

This is the mechanism used by to run the compiler tests on the MIPS
simulator, e.g., runtest using the mips-sim target.  For more
information, see http://gcc.gnu.org/simtest-howto.html.

Under the covers, how this work is that libgloss code is configured to
use one of several standard-ish MIPS firmware monitors, and jumps to
known service addresses that they provide.  sim/mips provides stubs at
those locations which use RSVD_INSTRUCTION to emulate the requested
operations.  (This enables, e.g., code compiled for the IDT mips
monitor to run on both the hardware and on the simulator.)


IMO, being able to emulate any particular OS environmnent (without
booting the OS itself 8-) just wasn't worth the effort.  It's a pain
to emulate enough syscalls and enough of the operating environment to
be useful.  The only time i *really* wanted this IIRC was when I was
trying to debug dynamic loader issues, and to do that you'd have to
emulate a *bunch* of stuff.


I don't quite recall the status of what got integrated, but the
exception handling, architecture emulation, and device emulation we
developed at SiByte/Broadcom was sufficient to enable a real OS kernel
to be run on the board.  E.g., we could boot a MIPS Linux or NetBSD
kernel on our simulator.  Programs running in userland on that run
syscalls, of course.  8-)  (You could even boot all the way to
multi-user, getting your root fs, etc., from NFS... IIRC we
contributed all that code to GDB, but I never got around to
integrating all of it.)  We contributed all the code back, but I don't
recall how much of it I integrated before I moved on.  (IIRC, the
contributed-back bits were supposed to be put up in the contrib area
on the FTP site, don't know if they ever made it there.)

If you're interested in pursuing any of that work, let me know.  I
have ... little interest in actually working on that code anymore, but
could probably answer questions about it.



good luck,

chris