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 <
[email protected]> wrote:
> On 5/30/19 2:07 PM, Michael Rolnik wrote:
> > From: Sarah Harris <[email protected]>
> >
> > 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
