[Qemu-devel] how to debug qemu?

[Qemu-devel] how to debug qemu?

[Vita Batrla]

Hi,

I'm running Solaris inside qemu (i386), Most of things work fine,
exactly like on real machine, however, running modular debugger (mdb) on
e.g. /bin/ls turns the virtual machine to worm brick every time I try
it. Same procedure works fine on real hardware. The virtual machine is
flooded by INT 0x01, because env->eflags & TF_MASK is set. How do I find
out which instruction turned TF flag on?

I'd like to find the original instruction, which did set TF flag by
instrumenting cpu_exec() right after the executing gen_func(). Can I get
it by examination env->current_tb?:

(gdb) print env->current_tb[0]
$7 = {pc = 4269802867, cs_base = 0, flags = 68276, size = 8, cflags = 0,
  tc_ptr = 0x8b4a630 "�\020", phys_hash_next = 0x0, page_next = {0x81599a0,
    0x0}, page_addr = {4194304, 4294967295}, tb_next_offset = {65535, 65535},
  tb_jmp_offset = {324, 244, 65535, 65535}, jmp_next = {0x0, 0x0},
  jmp_first = 0x81599e2}

Where is the non-translated assembler code, or how to find the
instruction more effectively? Can some one help me please?

Best regards,

Vita

[Qemu-devel] Re: how to debug qemu?

[Vita Batrla]

Again me,

I now see what the problem is, qemu doesn't update the status debug
register dr6 on single step trap:

Debug Status Register (DR6):

The BS bit is associated with the TF (trap flag) bit of the EFLAGS
register. The BS bit is set if the debug handler is entered due to the
occurrence of a single-step exception. The single-step trap is the
highest-priority debug exception; therefore, when BS is set, any of the
other debug status bits may also be set.

I added two lines in target-i386/helper.c:

void raise_interrupt(int intno, int is_int, int error_code,
                     int next_eip_addend)
{
+    if (intno == 1)
+        env->dr[6] |= 0x4000;

And mdb in Solaris works somehow now..

Vita

On Wed, 2007-02-28 at 10:35 +0100, Vita Batrla wrote:
> Hi,
> 
> I'm running Solaris inside qemu (i386), Most of things work fine,
> exactly like on real machine, however, running modular debugger (mdb) on
> e.g. /bin/ls turns the virtual machine to worm brick every time I try
> it. Same procedure works fine on real hardware. The virtual machine is
> flooded by INT 0x01, because env->eflags & TF_MASK is set. How do I find
> out which instruction turned TF flag on?
> 
> I'd like to find the original instruction, which did set TF flag by
> instrumenting cpu_exec() right after the executing gen_func(). Can I get
> it by examination env->current_tb?:
> 
> (gdb) print env->current_tb[0]
> $7 = {pc = 4269802867, cs_base = 0, flags = 68276, size = 8, cflags = 0,
>   tc_ptr = 0x8b4a630 "�\020", phys_hash_next = 0x0, page_next = {0x81599a0,
>     0x0}, page_addr = {4194304, 4294967295}, tb_next_offset = {65535, 65535},
>   tb_jmp_offset = {324, 244, 65535, 65535}, jmp_next = {0x0, 0x0},
>   jmp_first = 0x81599e2}
> 
> Where is the non-translated assembler code, or how to find the
> instruction more effectively? Can some one help me please?
> 
> Best regards,
> 
> Vita
>