[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaultsbecause tb
From: |
Erik van der Kouwe |
Subject: |
Re: [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaultsbecause tb_next[1] is NULL |
Date: |
Thu, 23 Aug 2007 21:38:01 +0200 |
Dear Ulrich,
I had a similar problem when fixing S/390 hosts. IIRC it was caused by
the "portable" GOTO_TB macro. On translation the goto is patched to jump
out of the block, which is something the compiler does not reckon with.
You may want to disassemble it and check if registers are overwritten
before the jump takes place.
Thank you for your reaction.
I have checked the disassabled code again, and I think on x86 something
different is going on, as the JMP instruction does not reference any
registers.
However it did seem useful to post what is going on in the generated code,
so I have included a list of disassembled instructions, the relevant memory
addresses and the registers at the time of the failure.
To me, it looks like the generated code makes sense (no obvious nonsensical
instructions or operands), but I am quite clueless what the translation
block field values are supposed to look like, and whether these values are
obviously wrong.
Disassambled generated instructions (the last opcode listed is the one that
causes the segmentation fault):
op_jz_subb
0000:002BC44E 807D2C00 cmp byte ptr [ebp+2C],00
0000:002BC452 7505 jnz 002BC459
0000:002BC454 E915000000 jmp 002BC46E
op_goto_tb0 [skipped because of the jump before]
0000:002BC459 FF256CC32B01 jmp dword ptr [012BC36C]
0000:002BC45F 89F6 mov esi,esi
op_movl_eip_im [skipped because of the jump before]
0000:002BC461 C745207FE00000 mov dword ptr [ebp+20],0000E07F
op_movl_T0_im [skipped because of the jump before]
0000:002BC468 BB40C32B01 mov ebx,012BC340
op_exit_tb [skipped because of the jump before]
0000:002BC46D C3 ret
op_goto_tb1
0000:002BC46E FF2570C32B01 jmp dword ptr [012BC370]
Registers at the time of failure below. The value at [ebp+2C] is 0.
fs gs ds es edi esi ebp ebx edx
000f000f 000f000f 000bcd53 00000000 06331f90 00004964 0000000f
ecx eax eip cs psw esp ss
00000000 00000000 00000000 00000007 00010246 0badd3cc 0000000f
The addresses 0x012BC36C and 0x012BC370 point into the "tbs" array in
"exec.c", which occupies the address range 0x012ae240-0x01aae240. The fields
pointed to are tb_next[0] and tb_next[1] respectively.
The following are the contents of the translation block pointed to:
target_ulong pc = 0x000fe05b;
target_ulong cs_base = 0x000f0000;
unsigned int flags = 0x00000044;
uint16_t size = 0x0024;
uint16_t cflags = 0x0000;
uint8_t *tc_ptr = 0x002bc330;
struct TranslationBlock *phys_hash_next = 0x00000000;
struct TranslationBlock *page_next[2] = { 0x00000000, 0x00000000 };
target_ulong page_addr[2] = { 0x0480e000, 0xffffffff };
uint16_t tb_next_offset[2]; = { 0xffff, 0xffff };
uint32_t tb_next[2]; = { 0x00000000, 0x00000000 };
struct TranslationBlock *jmp_next[2]; = { 0x00000000, 0x00000000 };
struct TranslationBlock *jmp_first; = 0x012bc342;
If anyone seems anything anomalous in the generated code and the contents of
the translation block i would love to hear it.
With kind regards,
Erik van der Kouwe