Re: [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaultsbecause tb_next[1] is NULL

["Erik van der Kouwe" <vdkouwe@cs.vu.nl>]

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