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

[Michael Rolnik <mrolnik@gmail.com>]

Just ran the test with simavr, once it hit BREAK, gdb stopped

On Wed, Jun 5, 2019 at 7:12 PM Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Michael Rolnik <mrolnik@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.henderson@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.henderson@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
>
>

-- 
Best Regards,
Michael Rolnik