1. There's a break instruction https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_BREAK.html 2. There's a set of tests that use break.
So I assume I have to implement this instruction as described in the spec. Sent from my cell phone, please ignore typos On Mon, Jun 3, 2019, 6:44 PM Richard Henderson <richard.hender...@linaro.org> wrote: > On 6/1/19 4:12 PM, Michael Rolnik wrote: > > 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 > > I was not suggesting using the internal qemu EXCP_DEBUG, but another AVR > specific exception, much the same way as every other cpu has a cpu-specific > debug exception. > > Or perhaps always do nothing. Why is gdb insertting BREAK in the first > place? > It should be using the "hardware breakpoint" support that qemu advertises > as > part of the gdbstub protocol, and that you support here: > > > + if (unlikely(cpu_breakpoint_test(cs, OFFSET_CODE + cpc * 2, > BP_ANY)) > > + || cpu_breakpoint_test(cs, OFFSET_DATA + cpc * 2, > BP_ANY)) { > > + tcg_gen_movi_i32(cpu_pc, cpc); > > + gen_helper_debug(cpu_env); > > + ctx.bstate = BS_EXCP; > > + goto done_generating; > > + } > > > > r~ >