gxemul-devel — Mailing list for discussions regarding GXemul's development

[GXemul-devel] ARM SBC instruction emulation does not set CPSR oVerflow bit

[Nilsson J. (ETAS-SEC/ENG-IDS) <Joe...@se...>]

Hello gxemul developers,

I have recently come across an anomaly in the emulation of the ARM SBC instruction. The case is as below.

GXEMUL VERSION:
0.6.1

ENVIRONMENT:
Debian

COMMAND:
gxemul -E 'testarm' mysimpleapp

CODE:
#include <inttypes.h>
int main(void)
{
    int ret = 0;
    int64_t min_signed = INT64_MIN;
    int64_t max_signed = INT64_MAX;
    if (max_signed > min_signed) {
        ret = 0;
    } else {
        ret = -1;
    }
    return ret;
}

COMPILER:
gcc-arm-non-eabi

RESULT:
Main returned nonzero!

DEBUG INFO (BEFORE):
0001023c:  e0d23004       sbcs       r3,r2,r4
BREAKPOINT: pc = 0x1023c
(The instruction has not yet executed.)
GXemul> reg
cpu0:  cpsr = nzcvqjeaIFt   pc = 0x0001023c  <main+0x68>
cpu0:  r0 = 0x00000000  r1 = 0x00000000  r2 = 0x80000000  r3 = 0xfffffffe
cpu0:  r4 = 0x7fffffff  r5 = 0x00000000  r6 = 0x00000000  r7 = 0x00000000
cpu0:  r8 = 0x00000000  r9 = 0x00000000  sl = 0x00000000  fp = 0x0001c9cc
cpu0:  ip = 0x00000000  sp = 0x0001c9a0  lr = 0x00010028
cpu0: cpsr = 0x000000d3 (SVC32)

DEBUG INFO (AFTER):
GXemul> step
0001023c:  e0d23004       sbcs       r3,r2,r4
GXemul> reg
cpu0:  cpsr = nZCvqjeaIFt   pc = 0x00010240  <main+0x6c>
cpu0:  r0 = 0x00000000  r1 = 0x00000000  r2 = 0x80000000  r3 = 0x00000000
cpu0:  r4 = 0x7fffffff  r5 = 0x00000000  r6 = 0x00000000  r7 = 0x00000000
cpu0:  r8 = 0x00000000  r9 = 0x00000000  sl = 0x00000000  fp = 0x0001c9cc
cpu0:  ip = 0x00000000  sp = 0x0001c9a0  lr = 0x00010028
cpu0: cpsr = 0x600000d3 (SVC32)

The expected is that the oVerflow bit of the CPSR is set, i.e. that CPSR is 0x700000d3.

Could anyone guide me as how to resolve this problem in the correct manner? I guess there is an update of the cpu_arm_instr_dpi.cc needed.

Best regards,
Joergen

[GXemul-devel] Patch: Fix console data loss due to interrupted writes

[Anders G. <ga...@gm...>]

gson wrote:

>        memset(&saction, 0, sizeof(saction));
>        saction.sa_handler = timer_tick;
>+       saction.sa_flags = SA_RESTART;
>
>        sigaction(SIGALRM, &saction, NULL);

Sounds very reasonable. The fix has been committed to trunk.
(http://gavare.se/gxemul/src/gxemul-trunk.tar.gz)


Anders

[GXemul-devel] Patch: Fix console data loss due to interrupted writes

[Andreas G. <gs...@gs...>]

Hi,

The NetBSD project runs automated tests of NetBSD/pmax and
NetBSD/hpcmips hosted on gxemul virtual machines:

  http://releng.netbsd.org/b5reports/pmax/
  http://releng.netbsd.org/b5reports/hpcmips/
  
The installation step of the tests has been randomly failing, and I
have now tracked down the cause: parts of the gxemul console output
are sometimes lost because write() system calls writing the console
output to stdout are interrupted by SIGALRM.  The following patch
appears to fix the problem.

--- src/old_main/timer.cc.orig	2018-12-07 06:29:22.000000000 +0000
+++ src/old_main/timer.cc
@@ -229,6 +229,7 @@ void timer_start(void)
 
 	memset(&saction, 0, sizeof(saction));
 	saction.sa_handler = timer_tick;
+	saction.sa_flags = SA_RESTART;
 
 	sigaction(SIGALRM, &saction, NULL);
 

[GXemul-devel] GXemul 0.6.1

[Anders G. <ga...@gm...>]

GXemul 0.6.1 is now available at http://gavare.se/gxemul/download.html

The main change between release 0.6.1 and 0.6.0.2 is:

o)  SGI O2 graphics emulation.

Previously, only serial console was possible when running NetBSD/sgimips as
a guest OS, but now it is also possible to use graphical framebuffer for
both text console and for X11.
- Also, OpenBSD/sgi has been moved from "unsupported" to supported.

For a detailed changelog, see the end of
http://gavare.se/gxemul/gxemul-stable/HISTORY.html .

[GXemul-devel] FPU emulation bug (-e 3max)

[Anders G. <ga...@gm...>]

co...@SD... wrote:
> While emulating netbsd/pmax (-e 3max) I ran into an issue with the
> output of the following command:
>
>   # awk 'BEGIN{ x=0; print x++; }'
>   2.22507e-308

Thanks for reporting this. It has been fixed in trunk now.

http://gavare.se/gxemul/src/gxemul-trunk.tar.gz


Anders

[GXemul-devel] GXemul 0.6.0.2

[Anders G. <ga...@gm...>]

GXemul 0.6.0.2 is now available at http://gavare.se/gxemul/download.html

The changes between release 0.6.0.2 and 0.6.0.1 are relatively minor. They
include:

o) Minor fixes to make it possible to build GXemul using relatively modern
compilers (GCC and clang).
o) Updating the guest OS installation instructions with newer versions of
guest OSes.
o) Legacy framework: MIPS: Bug fix for the case when a guest OS used
larger-than-4KB pages, when it comes to invalidating previous translations.
This makes e.g. recent versions of HelenOS on Malta run further than before.
o) New framework: Intel i960: Disassembly of i960CA instructions has been
implemented. Execution is not implemented yet, but disassembly support may
still be useful when debugging or inspecting i960 binaries.

For a detailed changelog, see the end of
http://gavare.se/gxemul/gxemul-stable/HISTORY.html (from 0.6.0.1 to
0.6.0.2).


Anders

Re: [GXemul-devel] Patch: don't crash on MIPS divide overflow

[Anders G. <ga...@gm...>]

>
> When emulating the MIPS DIV and DDIV instructions, check for divide
> overflow instead of performing the overflowing divide on the host and
> crashing the emulator.  This is needed to run recent versions of the
> NetBSD test suite on an emulated MIPS system.
>
> --- gxemul.old/work/gxemul-0.6.0.1/src/cpus/cpu_mips_instr.cc
>  2018-08-08 17:27:19.146417631 +0300
> +++ gxemul/work/gxemul-0.6.0.1/src/cpus/cpu_mips_instr.cc
>  2018-08-08 17:27:27.944250037 +0300
> @@ -1262,6 +1262,8 @@
>         int32_t res, rem;
>         if (b == 0)
>                 res = 0, rem = a;
> +       else if (a == (int32_t)0x80000000U && b == -1)
> +               res = 0, rem = 0;
>         else
>                 res = a / b, rem = a - b*res;
>         cpu->cd.mips.lo = (int32_t)res;
> @@ -1284,6 +1286,8 @@
>         int64_t res, rem;
>         if (b == 0)
>                 res = 0;
> +       else if (a == (int64_t)0x8000000000000000ULL && b == -1)
> +               res = 0;
>         else
>                 res = a / b;
>         rem = a - b*res;
>

Thanks Andreas. The fix is now in trunk. A snapshot can be found here for
testing: http://gavare.se/gxemul/news.html


Anders

[GXemul-devel] Patch: don't crash on MIPS divide overflow

[Andreas G. <gs...@gs...>]

When emulating the MIPS DIV and DDIV instructions, check for divide
overflow instead of performing the overflowing divide on the host and
crashing the emulator.  This is needed to run recent versions of the
NetBSD test suite on an emulated MIPS system.

--- gxemul.old/work/gxemul-0.6.0.1/src/cpus/cpu_mips_instr.cc	2018-08-08 17:27:19.146417631 +0300
+++ gxemul/work/gxemul-0.6.0.1/src/cpus/cpu_mips_instr.cc	2018-08-08 17:27:27.944250037 +0300
@@ -1262,6 +1262,8 @@
 	int32_t res, rem;
 	if (b == 0)
 		res = 0, rem = a;
+	else if (a == (int32_t)0x80000000U && b == -1)
+		res = 0, rem = 0;
 	else
 		res = a / b, rem = a - b*res;
 	cpu->cd.mips.lo = (int32_t)res;
@@ -1284,6 +1286,8 @@
 	int64_t res, rem;
 	if (b == 0)
 		res = 0;
+	else if (a == (int64_t)0x8000000000000000ULL && b == -1)
+		res = 0;
 	else
 		res = a / b;
 	rem = a - b*res;

[GXemul-devel] FPU emulation bug (-e 3max)

[<co...@SD...>]

Hi,

I'm not sure if it has been reported before.

While emulating netbsd/pmax (-e 3max) I ran into an issue with the
output of the following command:

  # awk 'BEGIN{ x=0; print x++; }'
  2.22507e-308

(equal to 2^(-1022), note awk uses doubles exclusively for numbers, and
netbsd/pmax is hard float)

This is with NetBSD-7.99.36 and GXemul 0.6.0.1 fro pkgsrc, which
includes some patches you may like, but none relevant to this bug.

Compared with a real DECstation 5000/33, it outputted 0 as expected, so
the fault is likely with GXemul.

Thanks.

[GXemul-devel] [PATCH] Fix compilation errors on OSX

[David H. <dho...@gm...>]

Hi,
I had some problems building gxemul on OSX where Clang is the default
compiler:

    error: pointer to function type cannot have 'const' qualifier

The attached patch fixes these issues.

Best regards,
David

[GXemul-devel] attempting to run NetBSD on any MIPS64 platform

[Daniel W. <dan...@gm...>]

Gxemul seems rather quiet these days.  I downloaded gxemul-0.6.0 and
tried to build it on a recent version of Ubuntu and it did not build.
It seems you guys are no longer interested?

I am attempting to run NetBSD on any MIPS64 platform, little endian
preferred.  Any advice would be great.  Can you recommend another
emulator?

Daniel

[GXemul-devel] using testversion from GITHUB

[Fausto S. <fau...@gm...>]

Hello,

i'm trying to install ULTRIX45 and I'm using an emulator version from
github:

https://github.com/CTSRD-CHERI/gxemul

It seems in that version there's an update to the math coprocessor that
could fix a bug I had using GMP library.

But after the boot from cdrom, when the system is starting from disk, I
have a cpu panic:

cpu 0 panic: init died
routine: 0x800ad884 called from: 0x8009d1d4
routine: 0x8009caf4 called from: 0x8009cadc
routine: 0x8009cac0 called from: 0x8013a984
routine: 0x8013a6c8 called from: 0x80129c54

TRACE ABORTED: trace confused


locks held by cpu 0

I compiled with gcc 4.7.3

thanks,
Fausto

Re: [GXemul-devel] mkstemp() issues

[George K. <xke...@ne...>]

Seems that svn trunk already has a fix:

http://gxemul.svn.sourceforge.net/viewvc/gxemul?view=revision&revision=5722
http://gxemul.svn.sourceforge.net/viewvc/gxemul?view=revision&revision=5801

--George Koehler

[GXemul-devel] mkstemp() issues

[Jeff R. <ri...@ta...>]

Here are a couple of patches to allow gxemul to work again on NetBSD, 
either is sufficient, but I would recommend both.

The first patch, to configure, looks for mkstemp() in stdlib.h (not 
unistd.h), which is the correct location.  I've left unistd.h there.

The second patch fixes mymkstemp() to open() with O_RDWR | O_CREAT 
instead of just O_RDWR, which is why mymkstemp() was failing on NetBSD 6.0.

+j

Re: [GXemul-devel] patch for DHCP

[Anders G. <ga...@gm...>]

Hi George,

Tis 2012-09-04 klockan 21:16 -0400 skrev George Koehler:
> GXemul responds to DHCP requests, but the responses are not valid.
> 
> Here is a patch so that NetBSD/pmax 5.1.2, running inside the emulator, 
> can use dhcpcd to configure the network.
> 
> First, this patch fixes the calculation for UDP checksums.  I deleted "- 
> 8".  This is so dhcpcd no longer complains about "invalid UDP packet".
> 
> Second, this patch adds these DHCP options: subnet mask, router, domain 
> name server, server identifier.  This is so dhcpcd does not "reject 
> DHCP"; it seems that dhcpcd requires the option for server identifier.
> 
> Where should I post the patch?  Here to gxemul-devel, or elsewhere?

Here is fine. I've applied the patch, and resynched SVN to sourceforge,
but haven't had time to test it with any other guest OS.

http://gxemul.svn.sourceforge.net/viewvc/gxemul?view=revision&revision=5803


Anders

[GXemul-devel] patch for DHCP

[George K. <xke...@ne...>]

GXemul responds to DHCP requests, but the responses are not valid.

Here is a patch so that NetBSD/pmax 5.1.2, running inside the emulator, 
can use dhcpcd to configure the network.

First, this patch fixes the calculation for UDP checksums.  I deleted "- 
8".  This is so dhcpcd no longer complains about "invalid UDP packet".

Second, this patch adds these DHCP options: subnet mask, router, domain 
name server, server identifier.  This is so dhcpcd does not "reject 
DHCP"; it seems that dhcpcd requires the option for server identifier.

Where should I post the patch?  Here to gxemul-devel, or elsewhere?

--George Koehler


Index: src/net/net_ip.cc
===================================================================
--- src/net/net_ip.cc    (revision 5802)
+++ src/net/net_ip.cc    (working copy)
@@ -936,7 +936,7 @@
   *
   *  Handle an IPv4 DHCP broadcast packet, coming from the emulated NIC.
   *
- *  Read http://www.ietf.org/rfc/rfc2131.txt for details on DHCP.
+ *  Read http://tools.ietf.org/html/rfc2131 for details on DHCP.
   *  (And http://users.telenet.be/mydotcom/library/network/dhcp.htm.)
   */
  static void net_ip_broadcast_dhcp(struct net *net, void *extra,
@@ -947,7 +947,7 @@
       */
  #if 1
      struct ethernet_packet_link *lp;
-    int i;
+    int i, reply_len;

      fatal("[ net: IPv4 DHCP: ");
  #if 1
@@ -1007,15 +1007,21 @@
       */
      fatal(" ]\n");

-    lp = net_allocate_ethernet_packet_link(net, extra, len);
+    reply_len = 307;
+    lp = net_allocate_ethernet_packet_link(net, extra, reply_len);

-    /*  Copy the old packet first:  */
-    memcpy(lp->data, packet, len);
+    /*  From old packet, copy everything before options field:  */
+    memcpy(lp->data, packet, 278);

      /*  We are sending to the client, from the gateway:  */
      memcpy(lp->data + 0, packet + 6, 6);
      memcpy(lp->data + 6, net->gateway_ethernet_addr, 6);

+        /*  Set IP length:  */
+    lp->data[16] = (reply_len - 14) >> 8;
+    lp->data[17] = (reply_len - 14) & 0xff;
+
+        /*  Set IP addresses:  */
      memcpy(lp->data + 26, &net->gateway_ipv4_addr[0], 4);
      lp->data[30] = 0xff;
      lp->data[31] = 0xff;
@@ -1026,6 +1032,10 @@
      memcpy(lp->data + 34, packet + 36, 2);
      memcpy(lp->data + 36, packet + 34, 2);

+    /*  Set UDP length:  */
+    lp->data[38] = (reply_len - 34) >> 8;
+    lp->data[39] = (reply_len - 34) & 0xff;
+
      /*  Client's (yiaddr) IPv4 address:  */
      lp->data[58] = 10;
      lp->data[59] = 0;
@@ -1040,11 +1050,35 @@

      snprintf((char *)lp->data + 70+16+64, 8, "gxemul");

+    /*  Options field at offset 278:  */
+    lp->data[278] = 99;
+    lp->data[279] = 130;
+    lp->data[280] = 83;
+    lp->data[281] = 99;
+
+    /*  DHCP options, http://tools.ietf.org/html/rfc1533  */
+    lp->data[282] = 1; /* subnet mask */
+    lp->data[283] = 4;
+    lp->data[284] = 255;
+    lp->data[285] = 0;
+    lp->data[286] = 0;
+    lp->data[287] = 0;
+    lp->data[288] = 3; /* router */
+    lp->data[289] = 4;
+    memcpy(lp->data + 290, &net->gateway_ipv4_addr[0], 4);
+    lp->data[294] = 6; /* domain name server */
+    lp->data[295] = 4;
+    memcpy(lp->data + 296, &net->gateway_ipv4_addr[0], 4);
+    lp->data[300] = 54; /* server identifier */
+    lp->data[301] = 4;
+    memcpy(lp->data + 302, &net->gateway_ipv4_addr[0], 4);
+    lp->data[306] = 255; /* end */
+
      /*  Recalculate IP header checksum:  */
      net_ip_checksum(lp->data + 14, 10, 20);

      /*  ... and the UDP checksum:  */
-    net_ip_tcp_checksum(lp->data + 34, 6, len - 34 - 8,
+    net_ip_tcp_checksum(lp->data + 34, 6, reply_len - 34,
          lp->data + 26, lp->data + 30, 1);

[GXemul-devel] SGI Indy ROM image

[folkert <fo...@va...>]

Hi,

I'm looking for a ROM image of an SGI Indy.
Anyone that can help me?


Folkert van Heusden

-- 
Ever wonder what is out there? Any alien races? Then please support
the seti@home project: setiathome.ssl.berkeley.edu
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

[GXemul-devel] (no subject)

[Fausto S. <fau...@gm...>]

Hello,

I'm trying to compile the latest svn version under Mac OS X, with

Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix

but I have these errors:

CPUDyntransComponent.cc:112:15: error: assigning to 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' from incompatible type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const';
                m_nextIC->f = GetDyntransToBeTranslated();
                                     ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPUDyntransComponent.cc:127:15: error: assigning to 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' from incompatible type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const';
                m_nextIC->f = GetDyntransToBeTranslated();
                                     ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPUDyntransComponent.cc:135:16: error: assigning to 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' from incompatible type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const';
                        m_nextIC->f = GetDyntransToBeTranslated();
                                             ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPUDyntransComponent.cc:176:15: error: assigning to 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' from incompatible type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const';
                m_nextIC->f = GetDyntransToBeTranslated();
                                     ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPUDyntransComponent.cc:186:15: error: assigning to 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' from incompatible type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const';
                m_nextIC->f = GetDyntransToBeTranslated();
                                     ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPUDyntransComponent.cc:197:9: error: cannot initialize a variable of type 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' with an rvalue of type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const'
  ...(*f)(CPUDyntransComponent*, DyntransIC*) = GetDyntransToBeTranslated();

      ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPUDyntransComponent.cc:428:9: error: assigning to 'void
      (*)(CPUDyntransComponent *, DyntransIC *)' from incompatible type 'void
      (*)(CPUDyntransComponent *, DyntransIC *) const';
                ic->f = GetDyntransToBeTranslated();
                        ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
7 errors generated.

I suppose this is a compiler problem, with gcc is all fine.
I'm not a c++ expert, so I don't know how to fix it.

Do you have a patch for this ?

thanks,
Fausto

Re: [GXemul-devel] GXemul ARM MSR fsxc patch

[Anders G. <ga...@gm...>]

Tis 2012-06-12 klockan 01:21 +0100 skrev James Peacock:
> Hello,

Hi James,

> I've been using GXemul to help develop a little project of mine and
> have noticed that the implementation of ARM MSR failed if the fields
> mask included the 's' or 'x' bits. Below is a patch to add basic
> support for these variants, which is enough to get code of the form
> 'MSR SPSR_fsxc' to run.
> 
> Also, when writing to the CPSR, the mask should be anded with
> 0xff000000 if the CPU is not in a privileged mode. I've not included
> this in the patch as it would be a much larger change the behaviour
> which I don't have the set up to test fully.

I applied the patch, and added an additional AND.

http://gxemul.svn.sourceforge.net/viewvc/gxemul?view=revision&revision=5800

I have not had time to do any stringent testing. (I tried a NetBSD/cats
5.1.2 install, which hung during disklabel. But I don't know if this was
due to the MSR instruction change.)

> GXemul has been incredibly useful. Is it still under any form of
> active development?

Not very active; development is extremely sporadic these days.


Anders

[GXemul-devel] GXemul ARM MSR fsxc patch

[James P. <ji...@gm...>]

Hello,

I've been using GXemul to help develop a little project of mine and
have noticed that the implementation of ARM MSR failed if the fields
mask included the 's' or 'x' bits. Below is a patch to add basic
support for these variants, which is enough to get code of the form
'MSR SPSR_fsxc' to run.

Also, when writing to the CPSR, the mask should be anded with
0xff000000 if the CPU is not in a privileged mode. I've not included
this in the patch as it would be a much larger change the behaviour
which I don't have the set up to test fully.

GXemul has been incredibly useful. Is it still under any form of
active development?

James


Index: src/cpus/cpu_arm.cc
===================================================================
--- src/cpus/cpu_arm.cc	(revision 5799)
+++ src/cpus/cpu_arm.cc	(working copy)
@@ -855,15 +855,12 @@
 		 */
 		if ((iw & 0x0fb0fff0) == 0x0120f000 ||
 		    (iw & 0x0fb0f000) == 0x0320f000) {
-			int a = (iw >> 16) & 15;
 			debug("msr%s\t%s", condition, (iw&0x400000)? "S":"C");
 			debug("PSR_");
-			switch (a) {
-			case 1:	debug("ctl"); break;
-			case 8:	debug("flg"); break;
-			case 9:	debug("all"); break;
-			default:debug(" UNIMPLEMENTED (a=%i)", a);
-			}
+                        if (iw & (1<<19)) debug("f");
+                        if (iw & (1<<18)) debug("s");
+                        if (iw & (1<<17)) debug("x");
+                        if (iw & (1<<16)) debug("c");
 			if (iw & 0x02000000) {
 				int r = (iw >> 7) & 30;
 				uint32_t b = iw & 0xff;
Index: src/cpus/cpu_arm_instr.cc
===================================================================
--- src/cpus/cpu_arm_instr.cc	(revision 5799)
+++ src/cpus/cpu_arm_instr.cc	(working copy)
@@ -2703,14 +2703,19 @@
 				imm = (imm >> 2) | ((imm & 3) << 30);
 			ic->arg[0] = imm;
 			ic->arg[2] = (size_t)(&cpu->cd.arm.r[rm]);
-			switch ((iword >> 16) & 15) {
-			case 1:	ic->arg[1] = 0x000000ff; break;
-			case 8:	ic->arg[1] = 0xff000000; break;
-			case 9:	ic->arg[1] = 0xff0000ff; break;
-			default:if (!cpu->translation_readahead)
-					fatal("unimpl a: msr regform\n");
-				goto bad;
-			}
+                        {
+                          uint32_t arg1 = 0;
+                          if (iword & (1<<16)) arg1 |= 0x000000ff;
+                          if (iword & (1<<17)) arg1 |= 0x0000ff00;
+                          if (iword & (1<<18)) arg1 |= 0x00ff0000;
+                          if (iword & (1<<19)) arg1 |= 0xff000000;
+                          if (arg1==0) {
+                                  if (!cpu->translation_readahead)
+                                          fatal("msr no fields\n");
+                                  goto bad;
+                          }
+                          ic->arg[1] = arg1;
+                        }
 			break;
 		}
 		if ((iword & 0x0fbf0fff) == 0x010f0000) {

Re: [GXemul-devel] error running ultrix 4.5

[Anders G. <ga...@gm...>]

Tor 2011-04-07 klockan 20:25 +0200 skrev Fausto Saporito:
> Hello all,
> 
> during a "make check" compiling gmp 5.0.1 I got this error:
> 
> 
> mpn_get_d wrong on overflow
>   n=1
>   exp   1024
>   sign  0
>   got   =[00 00 00 00 00 00 F0 7F] Infinity
>   want  =[FF FF FF FF FF FF EF 7F] 1.7976931348623157e+308
> UNIMPLEMENTED cop0 (func 0x00)
> to_be_translated(): TODO: unimplemented instruction:
> 0042f720: 42000000      cop0    0x02000000 (unimplemented)
> 
> and gxemul crashed.
> 
> I'm using 0.6.0, is it normal ?

Well, it is a bug :-| that much is obvious. It is hard to know exactly
what instruction went wrong though. Rounding modes and exceptions are
not really implemented, if I remember correctly.

It would be interesting to know exactly which instructions that
'mpn_get_d' tried to run.


Anders

[GXemul-devel] error running ultrix 4.5

[Fausto S. <fau...@gm...>]

Hello all,

during a "make check" compiling gmp 5.0.1 I got this error:


mpn_get_d wrong on overflow
  n=1
  exp   1024
  sign  0
  got   =[00 00 00 00 00 00 F0 7F] Infinity
  want  =[FF FF FF FF FF FF EF 7F] 1.7976931348623157e+308
UNIMPLEMENTED cop0 (func 0x00)
to_be_translated(): TODO: unimplemented instruction:
0042f720: 42000000      cop0    0x02000000 (unimplemented)

and gxemul crashed.

I'm using 0.6.0, is it normal ?

Thanks,
Fausto

Re: [GXemul-devel] ARM + MINIX

[Yana <op...@ya...>]

Hello,

I used GXemul with YanaKernel0 Prototype.
http://yana.jp/

2010/8/13, Anders Gavare <ga...@gm...>:
> I do not know much about the internals of MINIX, but if it is already
> more or less portably written, and if some other emulator or simulator
> can be used, then yes, it is likely that GXemul can be used as well.

I used MINIX with YanaKernel0 Prototype on the following computer system.
+ processor (GXemul(testarm,testmips))
+ YanaKernel0
+ MINIX kernel which depended on YanaKernel0
+ MINIX tasks and MINIX processes

And I want to use YanaKernel0 which was implemented by hardware.
+ processor which embeded YanaKernel0 (FPGA?)
+ MINIX kernel which depended on YanaKernel0
+ MINIX tasks and MINIX processes

Thanks,

Yana

Re: [GXemul-devel] ARM + MINIX

[Anders G. <ga...@gm...>]

Hi Mohammed,

Tor 2010-08-12 klockan 18:19 +0530 skrev Mohammed Rashad:
> Can i use GXemul for porting MINIX OS to ARM processors? 

I do not know much about the internals of MINIX, but if it is already
more or less portably written, and if some other emulator or simulator
can be used, then yes, it is likely that GXemul can be used as well.

There is no guarantee that GXemul emulates exactly any specific ARM cpu
model; the cpu emulation was implemented to get some guest OSes (i.e.
NetBSD) running. So you should treat GXemul as some kind of "generic
lowest common denominator" emulation of the ARM ISA.

You can either target the "testarm" machine, which is a basic ARM cpu
plus some devices that more-or-less work like in a real machine (serial
controller, interrupt controller, disk controller, ethernet controller,
and a raw framebuffer), or you could port to e.g. the CATS mode (if you
want VGA charcell output) or the Netwinder mode (if you want pixel-based
framebuffer output).


Anders

[GXemul-devel] ARM + MINIX

[Mohammed R. <moh...@gm...>]

Can i use GXemul for porting MINIX OS to ARM processors?