[Qemu-devel] QEMU 0.2 is out

[Qemu-devel] QEMU 0.2 is out

[Fabrice Bellard]

Most of the QEMU architecture is now finished. There are still 
complicated issues regarding thread locking. My main issue is that I 
would like to avoid locking the cpu emulator while doing 'tb_find()'.

DOSEMU is now working better (I was able to launch DOS Navigator and a 
small VGA demonstration). The speed seems reasonnable althought QEMU has 
to emulate both the DOS code _and_ the dosemu code itself !

About the Sparc code: is it possible to move the prolog and epilog 
generation from dyngen_code() to the cpu main loop ? It would ease a lot 
the precise exception handling and the direct block chaining.

For Alpha and Sparc, if someone has an account that I can use, I could 
make some debug to fix the last issues.

Fabrice.

Re: [Qemu-devel] QEMU 0.2 is out

[Falk Hueffner]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]


> For Alpha and Sparc, if someone has an account that I can use, I
> could make some debug to fix the last issues.

You can get an account on Alpha Linux from HP at
http://www.testdrive.compaq.com/, or I can give you one on my machine
if you send me a ssh key.

I've attached a patch with all my changes, it doesn't seem to work at
all though, I get sig11 on all tests. It used to work "mostly" about
two weeks ago. I don't have time right now to look into it...

I think the fault address reporting was only introduced in 2.4.20 on
Alpha, so it might not work on older kernels.

-- 
	Falk


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: qemu-alpha-2003.06.01.patch --]
[-- Type: text/x-patch, Size: 3781 bytes --]

Index: dyngen.c
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.16
diff -u -p -r1.16 dyngen.c
--- dyngen.c	29 May 2003 20:05:18 -0000	1.16
+++ dyngen.c	1 Jun 2003 18:15:02 -0000
@@ -691,7 +691,7 @@ void gen_code(const char *name, host_ulo
 			case R_ALPHA_BRSGP:
 			    /* PC-relative jump. Tweak offset to skip the two instructions that try to
 			       set up the gp from the pv.  */
-			    fprintf(outfile, "    fix_bsr(gen_code_ptr + %ld, (uint8_t *) &%s - (gen_code_ptr + %ld) + 4);\n",
+			    fprintf(outfile, "    fix_bsr(gen_code_ptr + %ld, (uint8_t *) &%s - (gen_code_ptr + %ld + 4) + 8);\n",
 				    rel->r_offset - start_offset, sym_name, rel->r_offset - start_offset);
 			    break;
 			default:
Index: exec-i386.c
===================================================================
RCS file: /cvsroot/qemu/qemu/exec-i386.c,v
retrieving revision 1.26
diff -u -p -r1.26 exec-i386.c
--- exec-i386.c	29 May 2003 20:04:28 -0000	1.26
+++ exec-i386.c	1 Jun 2003 18:15:03 -0000
@@ -447,6 +447,34 @@ int cpu_x86_signal_handler(int host_sign
                              is_write, &uc->uc_sigmask);
 }
 
+#elif defined(__alpha__)
+
+int cpu_x86_signal_handler(int host_signum, struct siginfo *info, 
+                           void *puc)
+{
+    struct ucontext *uc = puc;
+    uint32_t *pc = uc->uc_mcontext.sc_pc;
+    uint32_t insn = *pc;
+    int is_write = 0;
+
+    switch (insn >> 26) {
+    case 0x0d: // stw
+    case 0x0e: // stb
+    case 0x0f: // stq_u
+    case 0x24: // stf
+    case 0x25: // stg
+    case 0x26: // sts
+    case 0x27: // stt
+    case 0x2c: // stl
+    case 0x2d: // stq
+    case 0x2e: // stl_c
+    case 0x2f: // stq_c
+	is_write = 1;
+    }
+
+    return handle_cpu_signal(pc, (unsigned long)info->si_addr, 
+                             is_write, &uc->uc_sigmask);
+}
 #else
 
 #error CPU specific signal handler needed
Index: exec-i386.h
===================================================================
RCS file: /cvsroot/qemu/qemu/exec-i386.h,v
retrieving revision 1.17
diff -u -p -r1.17 exec-i386.h
--- exec-i386.h	29 May 2003 20:04:28 -0000	1.17
+++ exec-i386.h	1 Jun 2003 18:15:03 -0000
@@ -124,6 +124,8 @@ register unsigned int A0 asm("$11");
 register unsigned int EAX asm("$12");
 register unsigned int ESP asm("$13");
 register unsigned int EBP asm("$14");
+/* Note $15 is the frame pointer, so anything in op-i386.c that would
+   require a frame pointer, like alloca, would probably loose.  */
 register struct CPUX86State *env asm("$15");
 #define reg_EAX
 #define reg_ESP
Index: exec.h
===================================================================
RCS file: /cvsroot/qemu/qemu/exec.h,v
retrieving revision 1.3
diff -u -p -r1.3 exec.h
--- exec.h	27 May 2003 23:29:24 -0000	1.3
+++ exec.h	1 Jun 2003 18:15:03 -0000
@@ -214,7 +214,7 @@ static inline int testandset (int *p)
 #endif
 
 #ifdef __alpha__
-int testandset (int *p)
+static inline int testandset (int *p)
 {
     int ret;
     unsigned long one;
Index: op-i386.c
===================================================================
RCS file: /cvsroot/qemu/qemu/op-i386.c,v
retrieving revision 1.31
diff -u -p -r1.31 op-i386.c
--- op-i386.c	29 May 2003 20:04:27 -0000	1.31
+++ op-i386.c	1 Jun 2003 18:15:05 -0000
@@ -1762,16 +1762,16 @@ typedef union {
     double d;
 #ifndef WORDS_BIGENDIAN
     struct {
-        unsigned long lower;
-        long upper;
+        uint32_t lower;
+        int32_t upper;
     } l;
 #else
     struct {
-        long upper;
-        unsigned long lower;
+        int32_t upper;
+        uint32_t lower;
     } l;
 #endif
-    long long ll;
+    int64_t ll;
 } CPU86_LDoubleU;
 
 /* the following deal with IEEE double-precision numbers */

Re: [Qemu-devel] QEMU 0.2 is out

[Fabrice Bellard]

Falk Hueffner wrote:
>>For Alpha and Sparc, if someone has an account that I can use, I
>>could make some debug to fix the last issues.
> 
> 
> You can get an account on Alpha Linux from HP at
> http://www.testdrive.compaq.com/, or I can give you one on my machine
> if you send me a ssh key.
> 
> I've attached a patch with all my changes, it doesn't seem to work at
> all though, I get sig11 on all tests. It used to work "mostly" about
> two weeks ago. I don't have time right now to look into it...
> 
> I think the fault address reporting was only introduced in 2.4.20 on
> Alpha, so it might not work on older kernels.

I have now access to an Alpha and a Sparc computer.

For Alpha: I am using gcc 3.2.3 and '-msmall-text' is not supported. Is 
it really necessary ?

Fabrice.

Re: [Qemu-devel] QEMU 0.2 is out

[Falk Hueffner]

Fabrice Bellard <fabrice.bellard@free.fr> writes:

> For Alpha: I am using gcc 3.2.3 and '-msmall-text' is not
> supported. Is it really necessary ?

Not really, I was just hoping to avoid a few gp readjustments with it,
however it doesn't really seem to have that effect, since for
non-static functions, that cannot be done, and for static functions,
gcc already knows to avoid gp restoring.

-- 
	Falk

Re: [Qemu-devel] QEMU 0.2 is out

[Fabrice Bellard]

Falk Hueffner wrote:
> Fabrice Bellard <fabrice.bellard@free.fr> writes:
> 
> 
>>For Alpha: I am using gcc 3.2.3 and '-msmall-text' is not
>>supported. Is it really necessary ?
> 
> 
> Not really, I was just hoping to avoid a few gp readjustments with it,
> however it doesn't really seem to have that effect, since for
> non-static functions, that cannot be done, and for static functions,
> gcc already knows to avoid gp restoring.

Which version of gcc are you using ? Do you use a patched gcc ? Can you 
give me your spec file and the gcc -v log when you compile op-i386.c ?

I am totally unable to get correct code. In particular, I cannot make 
gcc 3.2.3 generate R_ALPHA_BRADDR relocations. Currently, to get correct 
code, I must do the following:
--
int __op_param1;
#define PARAM1 ({ int _r; asm("ldah %0,__op_param1($29) !gprelhigh\n" \
                               "lda %0,__op_param1(%0)   !gprellow" : 
"=r"(_r) ); _r; })

#define CALL(x) asm volatile ("bsr $26, %0" : : "i" (x))
--
and use the macro CALL to call a function!

Fabrice.

Re: [Qemu-devel] QEMU 0.2 is out

[Falk Hueffner]

Fabrice Bellard <fabrice.bellard@free.fr> writes:

> Which version of gcc are you using ? Do you use a patched gcc ? Can
> you give me your spec file and the gcc -v log when you compile
> op-i386.c ?

I use gcc 3.3 or 3.4 snapshots usually.

> I am totally unable to get correct code. In particular, I cannot make
> gcc 3.2.3 generate R_ALPHA_BRADDR relocations. Currently, to get
> correct code, I must do the following:
> 
> --
> int __op_param1;
> #define PARAM1 ({ int _r; asm("ldah %0,__op_param1($29) !gprelhigh\n" \
>                                "lda %0,__op_param1(%0) !gprellow" :
>                                "=r"(_r) ); _r; })

Ah yes, this is because gcc 3.2.3 doesn't support visibility("hidden")
yet. If a symbol has global visibility, gcc cannot know it is accessed
with the same gp, since it might be provided by libc for example. I
don't think there's any better way do this with 3.2.3.

> #define CALL(x) asm volatile ("bsr $26, %0" : : "i" (x))
> --
> and use the macro CALL to call a function!

This seems to works for me even with 3.2.3. What happens if you don't
use the macro? Maybe your binutils is too old? I have 2.14.90.0.4-0.1.

Also, concerning the signal handler, siginfo is only filled in with
2.4.20 and newer kernels...

-- 
	Falk

Re: [Qemu-devel] QEMU 0.2 is out

[Fabrice Bellard]

With gcc 3.3 and binutils 2.14.90.0.4 it is better. I fixed some bugs 
related to the new jump optimisation I introduced. But there is a big 
problem: no relocations are generated for calls to global functions if 
they are in the same file as the function call. I am trying various 
patches for this.

Fabrice.


Falk Hueffner wrote:
> Fabrice Bellard <fabrice.bellard@free.fr> writes:
> 
> 
>>Which version of gcc are you using ? Do you use a patched gcc ? Can
>>you give me your spec file and the gcc -v log when you compile
>>op-i386.c ?
> 
> 
> I use gcc 3.3 or 3.4 snapshots usually.
> 
> 
>>I am totally unable to get correct code. In particular, I cannot make
>>gcc 3.2.3 generate R_ALPHA_BRADDR relocations. Currently, to get
>>correct code, I must do the following:
>>
>>--
>>int __op_param1;
>>#define PARAM1 ({ int _r; asm("ldah %0,__op_param1($29) !gprelhigh\n" \
>>                               "lda %0,__op_param1(%0) !gprellow" :
>>                               "=r"(_r) ); _r; })
> 
> 
> Ah yes, this is because gcc 3.2.3 doesn't support visibility("hidden")
> yet. If a symbol has global visibility, gcc cannot know it is accessed
> with the same gp, since it might be provided by libc for example. I
> don't think there's any better way do this with 3.2.3.
> 
> 
>>#define CALL(x) asm volatile ("bsr $26, %0" : : "i" (x))
>>--
>>and use the macro CALL to call a function!
> 
> 
> This seems to works for me even with 3.2.3. What happens if you don't
> use the macro? Maybe your binutils is too old? I have 2.14.90.0.4-0.1.
> 
> Also, concerning the signal handler, siginfo is only filled in with
> 2.4.20 and newer kernels...
> 


-- 
Fabrice.

[Qemu-devel] QEMU on Alpha

[Fabrice Bellard]

Hi,

The CVS version of QEMU should now launch test-i386 successfully on 
Alpha. If you want to try it, read the README file to know what are the 
tested tools (gcc 3.3 is _required_). I tested it only with a 2.2 Linux 
kernel, so I was not able to test the precise exception support which 
requires a 2.4.20 kernel.

The remaining issues (in particular with ls) should only be related to 
bad syscall emulation, which is easier to fix.

Fabrice.

[Qemu-devel] QEMU on Alpha

[Alex Melnikov]

Hello!

What are the status of the Alpha host port?

I tryed 0.6.0 (i386-user and i386-softmmu targets), here is results:

i386-user:

Will not compile at default, because of redefinition problem in dyngen-exec.h (as 
mentioned by Falk Hueffner in http://lists.gnu.org/archive/html/qemu-devel/2004-
02/msg00080.html).

After commenting it (define uint64) - the i386-user target compiled ok (but with tons 
of warnings), but not works ok. I got gnemul libs and wine from main qemu site, but 
somehow wine can't run wineserver itself (all path, LD_LIBRARY_PATH, wine-setup.sh and 
so on - OK), need to run "wineserver -p" separately, but even after that, wine not run 
ok (it gives Unaligned access into /var/log/messages), and dont get any result when 
runned with "wine <any win32 binary>" (no error, just nothnig, and process qemu-i386 
wine just utilises about 0% of cpu), moreover "wine --help" gives error, 
but "wineserver --help" works normal (shows it help into stdout).

I tryed to run rar_static (x86 linux binary) - with this compiled qemu-i386, it only 
shows rar_help in stdout, but when i tryed to unpack rar archive with it - it gives 
error something like "can't seek in file test.rar".

i386-softmmu:

Seems broken? (no cpu_get_ticks form alpha, "unsupported cpu error" in vl.c)

Does anybody tryed current QEMU on Alpha Linux? Is the support of Alpha host is broken?


PS I use RedHat 7.2 with updated binutils-2.15.90 and gcc-3.3.4.

Re: [Qemu-devel] QEMU on Alpha

[Falk Hueffner]

Alex Melnikov <shurikkk@mail15.com> writes:

> What are the status of the Alpha host port?

It has never worked 100% and is currently pretty much broken.

> I tryed to run rar_static (x86 linux binary) - with this compiled
> qemu-i386, it only shows rar_help in stdout, but when i tryed to
> unpack rar archive with it - it gives error something like "can't
> seek in file test.rar".

First you should make sure you use gcc 3.3. Newer versions seem to do
something funny. Next it would be great if you could try to find some
very simple failing program (maybe write one?), to make debugging
easier. Last time I looked, it seemed to be something with signal
handling.

> i386-softmmu:
>
> Seems broken? (no cpu_get_ticks form alpha, "unsupported cpu error"
> in vl.c)

Alpha has a 32-bit cycle counter which could be used here, one just
would have to compensate for the frequent overflows. But it's probably
not worth bothering as long as the CPU emulation doesn't work...

-- 
	Falk

[Qemu-devel] qemu on alpha

[Gabriele Gorla]

Hello,
I recently downloaded qemu-0.9.0 and tried to compile
it on alpha.
I was not able to get any target to compile.

I searched the mailing list but I was not able to find
any recent information on the alpha host status.

I am using gcc-3.3.6 on debian stable with upgraded
kernel
2.6.22
I have tried with gcc-3.4 and 4.1 with similar
results.

I patched the line:
#if defined (__x86_64__) || defined(__ia64) ||
defined(__alpha__)
of file dyngen-exec.h to add the alpha to the 64-bit
architectures to prevent redefinition of int64_t and
uint64_t 

beside tons of warning about casting pointers to int
of different sizes I get the following two fatal
errors:

qemu-0.9.0/target-i386/ops_template.h:278: warning:
implicit declaration of function `GOTO_LABEL_PARAM'

qemu-0.9.0/target-i386/translate.c:1898: error: too
many arguments to function `gen_op_jnz_T0_label'
qemu-0.9.0/target-i386/translate.c:1900: error: too
many arguments to function `gen_op_jmp_label'

in the translate.c file the function is called with:
        gen_op_jmp_label(l2);

but in gen-op.h it is defined as:
static inline void gen_op_jmp_label(void)
{
    *gen_opc_ptr++ = INDEX_op_jmp_label;
}

same for gen_op_jnz_T0_label


for GOTO_LABEL_PARAM the definition is completely
missing from dyngen-exec.h (it is there for all other
host CPUs except m68k)

Unfortunately my understanding of the code is not
sufficient to do anything useful at this point.
I would really appreciate if someone could give me a
hint.

thanks,
GG






      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Qemu-devel] qemu on alpha

[Thiemo Seufer]

Gabriele Gorla wrote:
> Hello,
> I recently downloaded qemu-0.9.0 and tried to compile
> it on alpha.
> I was not able to get any target to compile.
> 
> I searched the mailing list but I was not able to find
> any recent information on the alpha host status.
> 
> I am using gcc-3.3.6 on debian stable with upgraded
> kernel
> 2.6.22
> I have tried with gcc-3.4 and 4.1 with similar
> results.
> 
> I patched the line:
> #if defined (__x86_64__) || defined(__ia64) ||
> defined(__alpha__)
> of file dyngen-exec.h to add the alpha to the 64-bit
> architectures to prevent redefinition of int64_t and
> uint64_t 
> 
> beside tons of warning about casting pointers to int
> of different sizes I get the following two fatal
> errors:
> 
> qemu-0.9.0/target-i386/ops_template.h:278: warning:
> implicit declaration of function `GOTO_LABEL_PARAM'
> 
> qemu-0.9.0/target-i386/translate.c:1898: error: too
> many arguments to function `gen_op_jnz_T0_label'
> qemu-0.9.0/target-i386/translate.c:1900: error: too
> many arguments to function `gen_op_jmp_label'
> 
> in the translate.c file the function is called with:
>         gen_op_jmp_label(l2);
> 
> but in gen-op.h it is defined as:
> static inline void gen_op_jmp_label(void)
> {
>     *gen_opc_ptr++ = INDEX_op_jmp_label;
> }
> 
> same for gen_op_jnz_T0_label
> 
> 
> for GOTO_LABEL_PARAM the definition is completely
> missing from dyngen-exec.h (it is there for all other
> host CPUs except m68k)
> 
> Unfortunately my understanding of the code is not
> sufficient to do anything useful at this point.
> I would really appreciate if someone could give me a
> hint.

Current CVS has probably less broken alpha host support. Still, it is
unlikely to work out of the box, fixing this requires some knowledge
of alpha assembler. (E.g. for implementing a GOTO_LABEL_PARAM for alpha.)


Thiemo

Re: [Qemu-devel] qemu on alpha

[Gabriele Gorla]

Thiemo wrote:
> Gabriele Gorla wrote:
> > Hello,
> > I recently downloaded qemu-0.9.0 and tried to
compile
> > it on alpha.
> > I was not able to get any target to compile.
> > 
> > beside tons of warning about casting pointers to
int
> > of different sizes I get the following two fatal
> > errors:
> > 
> > qemu-0.9.0/target-i386/ops_template.h:278:
warning:
> > implicit declaration of function
`GOTO_LABEL_PARAM'
> > 
> > qemu-0.9.0/target-i386/translate.c:1898: error:
too
> > many arguments to function `gen_op_jnz_T0_label'
> > qemu-0.9.0/target-i386/translate.c:1900: error:
too
> > many arguments to function `gen_op_jmp_label'
> > 
> > in the translate.c file the function is called
with:
> >         gen_op_jmp_label(l2);
> > 
> > but in gen-op.h it is defined as:
> > static inline void gen_op_jmp_label(void)
> > {
> >     *gen_opc_ptr++ = INDEX_op_jmp_label;
> > }
> > 
> > same for gen_op_jnz_T0_label
> > 
> > 
> > for GOTO_LABEL_PARAM the definition is completely
> > missing from dyngen-exec.h (it is there for all
other
> > host CPUs except m68k)
> > 
> > Unfortunately my understanding of the code is not
> > sufficient to do anything useful at this point.
> > I would really appreciate if someone could give me
a
> > hint.
>
> Current CVS has probably less broken alpha host 
> support. Still, it is
> unlikely to work out of the box, fixing this
requires 
> some knowledge
> of alpha assembler. (E.g. for implementing a 
> GOTO_LABEL_PARAM for alpha.)

Thiemo,
thanks for your reply.

I downloaded the latest CVS snapshot. It seems to be
slightly better as I do not have to patch for 64-bit
datatypes any longer.
However it still complains about gen_op_jnz_T0_label
and gen_op_jmp_label.

I am willing to spend time trying to figure out what
is wrong but I really need a little help to understand
where to look.

thanks,
GG 


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Qemu-devel] qemu on alpha

[Gabriele Gorla]

It seems I cannot send email to the mailing list from
my personal email account. Anyway... 
Here is what I discovered debugging the failure.
Is there anyone who can direct me to the next step?

thanks,
GG

> -------- Forwarded Message --------
> From: Gabriele Gorla <gorlik@penguintown.net>
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] qemu on alpha
> Date: Sat, 16 Feb 2008 22:11:21 -0800
> 
> Thiemo,
> thanks for your previous reply.
> I finally managed to compile qemu 0.9.1 on my
> machine (alpha ev68).
> 
> I had to add (as you suggested) the definition for
> GOTO_LABEL_PARAM:
> #define GOTO_LABEL_PARAM(n) asm volatile ("jmp
> "ASM_NAME(__op_gen_label)
> #n)
> 
> and I had to remove the -msmall-data option from the
> Makefile.target to
> make qemu link proprely.
> 
> Unfortunately I still can't run anything as qemu
> crashes very quickly
> when trying to execute the generated code.
> 
> Using gdb combined with qemu debug features I was
> able to narrow down
> the crash to the following instruction sequence:
> 
> ----------------
> IN:
> 0x400839f9:  pop    %ebx
> 0x400839fa:  add    $0x1104f,%ebx
> 0x40083a00:  xor    %eax,%eax
> 0x40083a02:  lea    0xfffffdec(%ebp),%edi
> 0x40083a08:  lea    0xfffeefa0(%ebx),%esi
> 0x40083a0e:  sub    0x84(%ebx),%esi
> 0x40083a14:  lea    0xfffffdbc(%ebp),%edx
> 0x40083a1a:  mov    %edx,0xfffffd90(%ebp)
> 0x40083a20:  lea    0xfffffdc0(%ebp),%ecx
> 0x40083a26:  mov    %ecx,0xfffffda0(%ebp)
> 0x40083a2c:  lea    0xfffffdc4(%ebp),%edx
> 0x40083a32:  mov    %edx,0xfffffd9c(%ebp)
> 0x40083a38:  lea    0xfffffdd4(%ebp),%ecx
> 0x40083a3e:  mov    %ecx,0xfffffd94(%ebp)
> 0x40083a44:  mov    %edi,%edx
> 0x40083a46:  movl   $0x0,(%edx,%eax,4)
> 0x40083a4d:  inc    %eax
> 0x40083a4e:  cmp    $0x61,%eax
> 0x40083a51:  jbe    0x40083a46
> 
> OUT: [size=936]
> 0x60589bb0: mov	s4,s2
> 0x60589bb4: zapnot s2,0xf,t0
> 0x60589bb8: ldl	s0,0(t0)
> 0x60589bbc: lda	s4,4(s4)
> 0x60589bc0: stl	s0,12(fp)
> 0x60589bc4: ldah gp,24606
> ...
> ...
> 0x60589e7c: ldah t0,0
> 0x60589e80: lda	t0,16(t0)
> 0x60589e84: mov	t0,t1
> 0x60589e88: stl	t1,48(fp)
> 0x60589e8c: ldl	t1,40(fp)
> 0x60589e90: ldl	t0,44(fp)
> 0x60589e94: addl t0,t1,t0
> 0x60589e98: cmpule t0,t1,t0
> 0x60589e9c: beq	t0,0x60589ea8
> 0x60589ea0: lda	t12,-22256(gp)
> 0x60589ea4: br	0x6071d244     <---- branch to
> uninitialized memory
> 0x60589ea8: ldah gp,24606
> 0x60589eac: lda	gp,-12160(gp)
> 0x60589eb0: ldah t0,24613
> 0x60589eb4: lda	t0,-25936(t0)
> ...
> ...
> 
> given the original instruction sequence I am a bit
> puzzled about the
> source of the offending branch instruction in the
> generated code.
> 
> do you have any suggestion on how to proceed?
> 
> thank,
> GG
> 


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Qemu-devel] qemu on alpha

[Thiemo Seufer]

Gabriele Gorla wrote:
> It seems I cannot send email to the mailing list from
> my personal email account. Anyway... 
> Here is what I discovered debugging the failure.
> Is there anyone who can direct me to the next step?

Things have changed considerably in the last few weeks. The code
generator is now TCG, which works currently only on x86 and x86_64
hosts. So you would need to create a TCG version for Alpha. Have a
look at the tcg subdirectory in the CVS version.


Thiemo