[Top][All Lists]
[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
fast-glibc-0.patch.gz
Description: fast-glibc-0.patch.gz
- [Qemu-devel] qemu-fast on Debian,
Piotr Krysik <=