Re: [PATCH] armv7m_nvic: set DHCSR.DEBUGEN when debugger is attached

[Peter Maydell]

On Fri, 4 Feb 2022 at 12:41, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Fri, 4 Feb 2022 at 09:28, Alex Bennée <alex.bennee@linaro.org> wrote:
> >> Assuming you are happy for the device to act as though a external
> >> debugger is attached regardless of the gdbstub state you could use a CPU
> >> property on the command line to enable this behaviour. We have some
> >> examples for SVE for the 64 bit CPUs (see object_property_add for
> >> sve-max-vq). So something like:
> >>
> >>   -cpu cortex-m3,dhscr=true
> >>
> >> You would probably want to model the behaviour of DHSCR.C_HALT as well
> >> because that is something the core might do to itself if it detects it
> >> is running under debug.
> >
> > This is sounding pretty hacky to me. I think we should either have
> > a proper implementation of all of halting debug (probably opt-in,
> > with the default being that the gdbstub is transparent to the guest),
>
> So we could flip it and make it a property of gdbstub with transparency
> being the default. Then any architecture that wanted to have this
> behaviour could query the stub if enabled.

I don't particularly mind how we expose it to the user. But I
do think that we should either not implement this architectural
feature at all or we should implement it properly. "Just this
one tiny part that happens to be the bit this one user wanted"
isn't a long-term sensible place to land IMHO.

> > or we should just say that no, this isn't something we support,
> > and if you want gdb to get control when a particular bit of code
> > is executed then you should set a breakpoint there.
>
> It's a fairly niche use case but I don't see why we shouldn't assuming
> someone is willing to write the code. However I suspect there is quite a
> wide range of potential behaviours to model.
>
> > We don't even implement the guest-visible debug parts of the
> > architecture (eg architected single-step) yet, incidentally.
>
> Is this just for Aarch32? Because for Aarch64 as far as I'm aware the
> v8.0 debug works fine modulo bugs which I sent a fix for:

This is M-profile specifically. It has guest-controllable
single-step but the mechanism is (as usual with M-profile)
completely different from the A-profile equivalent.

-- PMM