Michael Rolnik <mrol...@gmail.com> writes:
> Richard. > > We use break instruction for testing. (Here > https://github.com/seharris/qemu-avr-tests/tree/master/instruction-tests). > Each test is a big list of small tests with a break between them. We run > the tests on HW and on QEMU then compare register after each break. This is exactly the same process RISU uses for testing. But it works with a) linux-user and b) some architecturally defined illegal instruction that will cause a SIGILL. > If we > don't implement break the way Sarah suggested we have no way of > testing. So this is the behaviour of AVR simulator when gdb is attached? > What do you suggest? > > Sent from my cell phone, please ignore typos > > On Wed, Jun 5, 2019, 5:37 PM Richard Henderson <richard.hender...@linaro.org> > wrote: > >> On 6/5/19 2:20 AM, Michael Rolnik wrote: >> > Hi Richard. >> > >> > I am still struggling with this one. >> > >> > The spec says. >> > The BREAK instruction is used by the On-chip Debug system, and is >> normally not >> > used in the application software. >> > When the BREAK instruction is executed, the AVR CPU is set in the >> Stopped Mode. >> > This gives the On-chip Debugger access to internal resources. >> > If any Lock bits are set, or either the JTAGEN or OCDEN Fuses are >> unprogrammed, >> > the CPU will treat the BREAK instruction as a NOP and will not enter the >> > Stopped mode. >> >> Yep. >> >> > I read is as follows >> > - If user has an intention of using debugger, BREAK should be translated >> to >> > QEMU debug breakpoint >> > - If user has no intention of using debugger, BREAK should be translated >> into NOP. >> >> I do not read it that way. The spec is talking about a specific >> implementation >> of debugging -- fuses, jtag and all. We do not need to implement >> breakpoints >> using any of those mechanisms, because we can insert breakpoints via >> on-the-side data structures and re-translation. >> >> >> r~ >> > > On Wed, Jun 5, 2019, 5:37 PM Richard Henderson <richard.hender...@linaro.org> > wrote: > >> On 6/5/19 2:20 AM, Michael Rolnik wrote: >> > Hi Richard. >> > >> > I am still struggling with this one. >> > >> > The spec says. >> > The BREAK instruction is used by the On-chip Debug system, and is >> normally not >> > used in the application software. >> > When the BREAK instruction is executed, the AVR CPU is set in the >> Stopped Mode. >> > This gives the On-chip Debugger access to internal resources. >> > If any Lock bits are set, or either the JTAGEN or OCDEN Fuses are >> unprogrammed, >> > the CPU will treat the BREAK instruction as a NOP and will not enter the >> > Stopped mode. >> >> Yep. >> >> > I read is as follows >> > - If user has an intention of using debugger, BREAK should be translated >> to >> > QEMU debug breakpoint >> > - If user has no intention of using debugger, BREAK should be translated >> into NOP. >> >> I do not read it that way. The spec is talking about a specific >> implementation >> of debugging -- fuses, jtag and all. We do not need to implement >> breakpoints >> using any of those mechanisms, because we can insert breakpoints via >> on-the-side data structures and re-translation. >> >> >> r~ >> -- Alex Bennée
