[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):

 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

 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

reply via email to

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