qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] qemu-fast on Debian


From: Piotr Krysik
Subject: [Qemu-devel] qemu-fast on Debian
Date: Thu, 19 Aug 2004 04:56:36 -0700 (PDT)

Hi!

While testing qemu-fast on Debian/unstable host 
I noticed two problems:
  * for some combination gcc and flags used to 
    compile qemu I get "Illegal instruction" fault;
  * when using -d xxxx option, I always get 
    "Segmentation fault".

I get "Illegal instruction" fault when code 
generated by gcc uses different policy for storing 
outgoing parameters then assumed in qemu. For example 
op_jz_ecxw_im may be compiled as:
    5db0:       sub    $0x4,%esp
    5db3:       cmpw   $0x0,0x4(%ebp)
    5db8:       jne    5de3 <op_jz_ecxw_im+0x33>
    5dba:       testb  $0x1,0x25(%ebp)
    5dbe:       movl   $0x0,0x20(%ebp)
    5dc5:       je     5de0 <op_jz_ecxw_im+0x30>
    5dc7:       movl   $0x1,(%esp)
    5dce:       call   5dcf <op_jz_ecxw_im+0x1f>
    5dd3:       lea    0x0(%esi),%esi
    5dd9:       lea    0x0(%edi),%edi
    5de0:       xor    %ebx,%ebx
    5de2:       ret    
    5de3:       pop    %ecx
    5de4:       ret    
When block is exited by ret at 5de2, the stack 
pointer is not correctly restored. The ret comes 
from EXIT_TB().

To fix the problem I propose to store stack pointer 
in a variable (new CPUState field?) before entering 
translated code and restore it on exit. Does anyone 
have better idea?

The second problem is probably caused by memory 
layout inconsistent with glibc assumption. I'm 
attaching a patch to work-around the problem (tested 
with libc6-dev 2.3.2.ds1-16).


Regards,

Piotrek


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Attachment: fast-glibc-0.patch.gz
Description: fast-glibc-0.patch.gz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]