qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v20 3/8] target/avr: Add mechanism to check


From: Michael Rolnik
Subject: Re: [Qemu-devel] [PATCH RFC v20 3/8] target/avr: Add mechanism to check for active debugger connection
Date: Sun, 2 Jun 2019 00:12:38 +0300

Hi Richard.

If I implement it this way

```
 static bool trans_BREAK(DisasContext *ctx, arg_BREAK *a)
 {
     if (avr_feature(ctx->env, AVR_FEATURE_BREAK) == false) {
         gen_helper_unsupported(cpu_env);
     } else {
         tcg_gen_movi_tl(cpu_pc, ctx->inst[0].npc);
         gen_helper_debug(cpu_env);
     }

     ctx->bstate = BS_EXCP;

     return true;
 }
```

qemu (without -s -S flags) crashes when debugger is not connected @
gdb_set_stop_cpu, after having fixed it as follows it stops right after the
BREAK and does not advance, however when gdb is connected it works fine.
```
 void gdb_set_stop_cpu(CPUState *cpu)
 {






*     GDBProcess *p;     if (!gdbserver_state) {         return;     }
 p = gdb_get_cpu_process(gdbserver_state, cpu);*

     if (!p->attached) {
         /*
          * Having a stop CPU corresponding to a process that is not
attached
          * confuses GDB. So we ignore the request.
          */
         return;
     }

     gdbserver_state->c_cpu = cpu;
     gdbserver_state->g_cpu = cpu;
 }
```



On Fri, May 31, 2019 at 4:54 PM Richard Henderson <
address@hidden> wrote:

> On 5/30/19 2:07 PM, Michael Rolnik wrote:
> > From: Sarah Harris <address@hidden>
> >
> > AVR CPUs have a BREAK instruction which behaves differently depending on
> whether debugging is enabled.
> > Since the hardware fuses that normally control this are difficult to
> emulate, and the BREAK instruction is useful for testing, the BREAK
> instruction is instead enabled/disabled depending on whether a GDB session
> is attached.
>
> I don't think that this is the right way to model this.
>
> I think that BREAK should always raise an exception and return to the main
> loop.  If there we find that the debugger is not attached, the main loop
> will
> simply continue.  Which becomes a nop, as documented.
>
>
> r~
>


-- 
Best Regards,
Michael Rolnik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]