[Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaults because tb_next[1] is NULL

[Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaults because tb_next[1] is NULL

[Erik van der Kouwe]

Dear all,

I have been attempting to get QEMU to run on the Minix operation system 
(running on x86, see http://www.minix3.org/ for more info on the OS) for 
some time now. I have gotten the program to compile and have added the 
Minix-specific a.out-like format to dyngen. I am quite certain this bit 
works, as I have been looking at the generated relocated code in the 
disassebler at length.

My problem is the following: quickly after starting I get a segmentation 
fault while the generated code is running.

This happens in the code generated from op_goto_tb1 and is caused by jumping 
to a NULL pointer. This NULL pointer originates from the tb_next[1] field of 
the translation block data structure passed as a parameter. I have verified 
in the disassembler that the parameter in the generated code is processed 
correctly and the field is indeed tb_next[1].

I would like to know what would be the normal place for tb_next[1] to be 
initialized, and perhaps if anyone has a suggesting why that might not be 
happening in this case.

I found that (but please correct me if I am wrong) the assignment can only 
take place in tb_set_jmp_target, which in turn is called only by tb_add_jump 
and tb_reset_jump. When stepping through the code I found that neither of 
these functions is ever called either.

Versions i'm using:
- Qemu 0.8.2 (newest when i started, but from changelog ISTM upgrading to 
0.9.0 would not help)
- Minix 3.1.2 (current release version)
- GCC 3.4.3 (version that comes with Minix)

Compilation settings:
- Target: i386-softmmu (must use soft MMU, Minix does not support paging)
- target_user_only enabled
- CONFIG_SOFTFLOAT enabled (Minix does not support FPU, everything is 
emulated anyways)
- USE_DIRECT_JUMP disabled (but had similar problem before disabling, and 
this seems easier to debug)

Virtual machine:
- The Linux image at http://fabrice.bellard.free.fr/qemu/linux-0.2.img.bz2

If you need any more information to answer my question (or at least guide me 
in the right direction) do not hesitate to ask.

Thanks in advance for any answers, suggestions or other advice you may have.

With kind regards,
Erik van der Kouwe 

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

[Ulrich Hecht]

On Wednesday 22 August 2007, Erik van der Kouwe wrote:
> My problem is the following: quickly after starting I get a
> segmentation fault while the generated code is running.
>
> This happens in the code generated from op_goto_tb1 and is caused by
> jumping to a NULL pointer. This NULL pointer originates from the
> tb_next[1] field of the translation block data structure passed as a
> parameter. I have verified in the disassembler that the parameter in
> the generated code is processed correctly and the field is indeed
> tb_next[1].

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.

CU
Uli

-- 
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

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

[Erik van der Kouwe]

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