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

[Alex Bennée]

Michael Rolnik <address@hidden> 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 <address@hidden>
> 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 <address@hidden>
> 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