From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IOIVO-00086p-OJ for qemu-devel@nongnu.org; Thu, 23 Aug 2007 15:38:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IOIVM-00086V-6U for qemu-devel@nongnu.org; Thu, 23 Aug 2007 15:38:10 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IOIVM-00086S-2Z for qemu-devel@nongnu.org; Thu, 23 Aug 2007 15:38:08 -0400 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IOIVL-0006P2-Lo for qemu-devel@nongnu.org; Thu, 23 Aug 2007 15:38:07 -0400 Message-ID: <002f01c7e5bd$1dc86340$0200a8c0@Feanor> From: "Erik van der Kouwe" References: <000301c7e4eb$24b81600$0200a8c0@Feanor> <200708231137.28138.uli@suse.de> 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 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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