mips sim syscall

mips sim syscall

[Masao Uebayashi]

Hi!

I'm new to this list.

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?

And it'd be possible to emulate only simple system calls (e.g.,
read(2), write(2), ...) by executing native ones, right?  Is there any
specific reason why MIPS interp.c doesn't do this OTOH sim/sh/interp.c
does?  Am I missing anything?

Masao

Re: mips sim syscall

[Chris Demetriou]

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

Re: mips sim syscall

[Masao Uebayashi]

Thanks for the reply.

My intention at the moment is to run GCC testsuite in cross manner.
I'll visit to fix ld.elf_so for NetBSD/mips N32 support later. :)

On NetBSD (and probably other *nixes) syscall number is put in V0
rather than exception vector offset.  I cheated the `reason' parameter
to bet set the correct syscall number.  I could kind of run a simplest
program calling _exit() implicitly with this patch.

(I'll look further to run GDB testsuite next Monday.)

Masao

Index: gnu/dist/gdb/sim/mips/interp.c
===================================================================
RCS file: /cvsroot/seil3/src/gnu/dist/gdb/sim/mips/interp.c,v
retrieving revision 1.2
diff -u -d -r1.2 interp.c
--- gnu/dist/gdb/sim/mips/interp.c	9 Dec 2007 12:40:27 -0000	1.2
+++ gnu/dist/gdb/sim/mips/interp.c	6 Jun 2008 10:17:52 -0000
@@ -699,10 +699,18 @@
       sim_write (sd, 0x80000000, (char *) halt, sizeof (halt));
       sim_write (sd, 0x80000180, (char *) halt, sizeof (halt));
       sim_write (sd, 0x80000200, (char *) halt, sizeof (halt));
+/*
+ * XXXNETBSD
+ * http://www.cygwin.com/ml/gdb-patches/2002-04/msg00604.html
+ */
+#if 0
+      /* This is wrong.  We're not supposed to write code to the
+	 vector tables, but rather pointers to code.  */
       /* XXX: Write here unconditionally? */
       sim_write (sd, 0xBFC00200, (char *) halt, sizeof (halt));
       sim_write (sd, 0xBFC00380, (char *) halt, sizeof (halt));
       sim_write (sd, 0xBFC00400, (char *) halt, sizeof (halt));
+#endif
     }
   }
 
@@ -1219,6 +1227,7 @@
 	break;
       }
 
+    case 1: /* void exit() */
     case 17: /* void _exit() */
       {
 	sim_io_eprintf (sd, "sim_monitor(17): _exit(int reason) to be coded\n");
@@ -1716,7 +1725,12 @@
           perform this magic. */
        if ((instruction & RSVD_INSTRUCTION_MASK) == RSVD_INSTRUCTION)
 	 {
+/* XXXNETBSD */
+#if 0
 	   int reason = (instruction >> RSVD_INSTRUCTION_ARG_SHIFT) & RSVD_INSTRUCTION_ARG_MASK;
+#else
+	   int reason = V0 << 1;
+#endif
 	   if (!sim_monitor (SD, CPU, cia, reason))
 	     sim_io_error (sd, "sim_monitor: unhandled reason = %d, pc = 0x%s\n", reason, pr_addr (cia));
 

Re: mips sim syscall

[David Daney]

Masao Uebayashi wrote:
> Thanks for the reply.
> 
> My intention at the moment is to run GCC testsuite in cross manner.
> I'll visit to fix ld.elf_so for NetBSD/mips N32 support later. :)
> 

For that you can run Linux under qemu.  You can install a complete 
mipsel-linux Debian distribution on any platform that runs qemu.

Also instructions for running the GCC testsuite in the sim can be found 
here:

http://gcc.gnu.org/simtest-howto.html

David Daney

Re: mips sim syscall

[Masao Uebayashi]

> For that you can run Linux under qemu.  You can install a complete 
> mipsel-linux Debian distribution on any platform that runs qemu.

Do you mean GCC team uses this as the official test method?

Masao

Re: mips sim syscall

[David Daney]

Masao Uebayashi wrote:
>> For that you can run Linux under qemu.  You can install a complete 
>> mipsel-linux Debian distribution on any platform that runs qemu.
>>     
>
> Do you mean GCC team uses this as the official test method?
>   
That is one way GCC is tested.  We have real hardware also.  It is 
fortunate that the qemu test results often match those run on real MIPS 
hardware.

As far as I know there is no *official* test method, only guidelines as 
to how patches should be tested before they are considered for inclusion.

David Daney