Arm arch5 support

The attached patch adds qemu target support for the new arm instructions present in the armv5e instruction set.

I'm probably going to look at adding thumb support next, time permitting.

Paul

Index: cpu-exec.c
===================================================================
RCS file: /cvsroot/qemu/qemu/cpu-exec.c,v
retrieving revision 1.38

diff -u -p -r1.38 cpu-exec.c
@@ -166,7 +166,8 @@ int cpu_exec(CPUState *env1)
         env->CF = (psr >> 29) & 1;
         env->NZF = (psr & 0xc0000000) ^ 0x40000000;
         env->VF = (psr << 3) & 0x80000000;
-        env->cpsr = psr & ~0xf0000000;
+        env->QF = (psr >> 27) & 1;
+        env->cpsr = psr & ~0xf8000000;
     }
 #elif defined(TARGET_SPARC)
 #elif defined(TARGET_PPC)

@@ -296,7 +297,7 @@ int cpu_exec(CPUState *env1)
 #elif defined(TARGET_ARM)
                     env->cpsr = compute_cpsr();
                     cpu_arm_dump_state(env, logfile, 0);
-                    env->cpsr &= ~0xf0000000;
+                    env->cpsr &= ~0xf8000000;
 #elif defined(TARGET_SPARC)
                     cpu_sparc_dump_state (env, logfile, 0);
 #elif defined(TARGET_PPC)

Index: target-arm/cpu.h
===================================================================
RCS file: /cvsroot/qemu/qemu/target-arm/cpu.h,v
retrieving revision 1.3

diff -u -p -r1.3 cpu.h
@@ -35,6 +35,7 @@ typedef struct CPUARMState {
     uint32_t CF; /* 0 or 1 */
     uint32_t VF; /* V is the bit 31. All other bits are undefined */
     uint32_t NZF; /* N is bit 31. Z is computed from NZF */
+    uint32_t QF; /* 0 or 1 */
 
     /* exception/interrupt handling */
     jmp_buf jmp_env;

Index: target-arm/exec.h
===================================================================
RCS file: /cvsroot/qemu/qemu/target-arm/exec.h,v
retrieving revision 1.1

diff -u -p -r1.1 exec.h
@@ -36,5 +36,5 @@ static inline int compute_cpsr(void)
     int ZF;
     ZF = (env->NZF == 0);
     return env->cpsr | (env->NZF & 0x80000000) | (ZF << 30) | 
-        (env->CF << 29) | ((env->VF & 0x80000000) >> 3);
+        (env->CF << 29) | ((env->VF & 0x80000000) >> 3) | (env->QF << 27);
 }

Index: target-arm/op.c
===================================================================
RCS file: /cvsroot/qemu/qemu/target-arm/op.c,v
retrieving revision 1.3

Index: target-arm/translate.c
===================================================================
RCS file: /cvsroot/qemu/qemu/target-arm/translate.c,v retrieving revision 1.10

Hi Paul,

Have you actually succeeded in getting ARM binaries to run? I just get this all the time (this is with your patch, but I get the same effect without it):

phi% armv5te-redhat-linux-gcc -Wall -o hi hi.c -static phi% /tmp/qemu/bin/qemu-arm ./hi
qemu: uncaught target signal 11 (Segmentation fault) - exiting phi%

The binaries generated with this toolchain run fine on a PXA25x, and with -mbig-endian they run fine on an Intel IXP2400.

cheers,
Lennert

I've only run some test assembly code inside an armv4 binary.

Code for "t" variants (maybe all armv5 targets) probably uses the bx thumb interworking instruction, which isn't implemented yet.

Paul

OK.. I get the same thing with armv5e-redhat-linux (just built a few new toolchains):

phi% cat hi.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()

{
	write(1, "hi!\n", 4);
	return 0;
}

phi% /opt/crosstool/armv5e-redhat-linux/gcc-3.3.3-glibc-2.3.2/bin/armv5e-redhat-linux-gcc -o hi hi.c -static phi% /tmp/qemu/bin/qemu-arm ./hi
qemu: uncaught target signal 11 (Segmentation fault) - exiting
phi%

And with armv4e-redhat-linux:

phi% /opt/crosstool/armv4e-redhat-linux/gcc-3.3.3-glibc-2.3.2/bin/armv4e-redhat-linux-gcc -Wall -o hi hi.c -static phi% /tmp/qemu/bin/qemu-arm ./hi
qemu: uncaught target signal 11 (Segmentation fault) - exiting
phi%

Your armv4 binaries do work, so do you maybe have any suggestions for a target triple I should use?

thanks,
Lennert

I didn't mean to sound as if I don't believe you.. in fact, I vaguely remember having succeeded in running ARM binaries in the past, but can't remember how and when. I'm just wondering what you're doing differently that causes it to work for you, and not for me and some other people on this list who've tried in the past.

--L

arm-linux, armv4-linux adn armv5te-redhat-linux-gnu toolchains all work. I've run the gcc testsuite on the arm-linux, and am only getting a handful of unexpected failures. The other two I've only verified that "Hello World" works.

The toolchains I've built are all configured for static libraries only. I have run dynamically linked programs from a debian-arm chroot.

FWIW I'm using CVS HEAD binutils and glibc, and a very slightly modified csl-arm (CodeSourcery) gcc.

qemu from cvs head as of yesterday

Paul

I may have found the cause.

It looks like nested functions (ie. stack trampolines) are broken, and cause errors similar to the one you're seeing. IIRC some versions of glibc use nested functions.

Paul