Re: [Qemu-devel] [PATCH] i386: fix breakpoints handling in icount mode

[Jan Kiszka]

On 2015-01-12 09:26, Pavel Dovgaluk wrote:
>> From: Jan Kiszka [mailto:address@hidden
>> On 2014-10-22 13:38, Pavel Dovgalyuk wrote:
>>> This patch fixes instructions counting when execution is stopped on
>>> breakpoint (e.g. set from gdb). Without a patch extra instruction is 
>>> translated
>>> and icount is incremented by invalid value (which equals to number of
>>> executed instructions + 1).
>>>
>>> Signed-off-by: Pavel Dovgalyuk <address@hidden>
>>> ---
>>>  target-i386/translate.c |    3 ++-
>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/target-i386/translate.c b/target-i386/translate.c
>>> index 1284173..193cf9f 100644
>>> --- a/target-i386/translate.c
>>> +++ b/target-i386/translate.c
>>> @@ -8000,7 +8000,7 @@ static inline void 
>>> gen_intermediate_code_internal(X86CPU *cpu,
>>>                  if (bp->pc == pc_ptr &&
>>>                      !((bp->flags & BP_CPU) && (tb->flags & HF_RF_MASK))) {
>>>                      gen_debug(dc, pc_ptr - dc->cs_base);
>>> -                    break;
>>> +                    goto done_generating;
>>>                  }
>>>              }
>>>          }
>>> @@ -8049,6 +8049,7 @@ static inline void 
>>> gen_intermediate_code_internal(X86CPU *cpu,
>>>              break;
>>>          }
>>>      }
>>> +done_generating:
>>>      if (tb->cflags & CF_LAST_IO)
>>>          gen_io_end();
>>>      gen_tb_end(tb, num_insns);
>>>
>>>
>>>
>>
>> Didn't looked into why, just bisected that this patch breaks at least
>> certain guest-originated break- or watchpoints in TCG mode. Can be
>> triggered by booting a Linux kernel with kgdb self-tests enabled. The
>> result is some false reporting of a host-originated debug stop to
>> gdb_set_stop_cpu while gdbserver_state is NULL -> SEGV.
> 
> It seems that kernel sets some hardware breakpoints and QEMU tries to process 
> them with GDB stub. Modifying gdb_set_stop_cpu should help:
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index e4a1a79..e8ef546 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1202,8 +1202,10 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  
>  void gdb_set_stop_cpu(CPUState *cpu)
>  {
> -    gdbserver_state->c_cpu = cpu;
> -    gdbserver_state->g_cpu = cpu;
> +    if (gdbserver_state) {
> +        gdbserver_state->c_cpu = cpu;
> +        gdbserver_state->g_cpu = cpu;
> +    }
>  }
>  
>  #ifndef CONFIG_USER_ONLY

I think this would only cure a symptom, but it doesn't explain why we
now hit cpu_handle_guest_debug which we do not before the patch:

(gdb) bt
#0  gdb_set_stop_cpu (address@hidden) at /data/qemu/gdbstub.c:1193
#1  0x000055555562dfdf in cpu_handle_guest_debug (cpu=0x55555663ac40) at 
/data/qemu/cpus.c:636
#2  tcg_exec_all () at /data/qemu/cpus.c:1389
#3  qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /data/qemu/cpus.c:1033
#4  0x00007ffff2c3d0a4 in start_thread () from /lib64/libpthread.so.0
#5  0x00007fffeea4a7fd in clone () from /lib64/libc.so.6

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux