Re: [RFC PATCH] target/arm: report M-profile BKPT to gdbstub when attached

["Alex Bennée" <alex.bennee@linaro.org>]

gilles grimaud <gilles.grimaud@univ-lille.fr> writes:

> Thanks everyone for the detailed comments.
>
> Let me try to summarize where I think the discussion stands, and then go through the questions that have emerged, from the most
> specific ones to the more general and still unresolved ones.
>
> My RFC originally came from reading QEMU's gdbstub as, at least conceptually, an analogue of an external low-level debugger such as
> a JTAG-attached debugger. From that perspective, having an attached GDB client consume a guest BKPT used as an external
> debugger stop point seemed natural.
>
<snip>
>
> ```
> Should the external debugger get a first chance to consume the debug event,
> and if it does not, should the event be reinjected into the guest?
> ```
>
> For Cortex-M, a rule that simply maps every BKPT to EXCP_DEBUG whenever GDB is attached could clearly steal an exception that
> should have remained guest-visible.
>
> This means that any generic abstraction would need to define not only when an external debugger may intercept a guest breakpoint
> instruction, but also what happens when it does not consume it.
>
> 5. Should QEMU's gdbstub be modelled as an external debug monitor?
>
> This now seems to me to be the most general question behind the RFC.
>
> If the answer is yes, then some variant of the behaviour I proposed seems natural: a breakpoint instruction that would be consumed
> by an external debugger on real hardware should be reportable to an attached GDB client.
>
> If the answer is no, then I think we need to clarify what the intended relationship is between QEMU's gdbstub and the architecture's
> external debug facilities.
>
> Alex's remark captures the current situation well:
>
>> "We could treat gdbstub as an external debug monitor but we don't currently model it as such."
>
> So perhaps the main remaining design question is where this abstraction should live.
>
> Should target-specific code directly know whether GDB is attached, as in my RFC?
>
> Or should there be a generic QEMU debug layer representing an external debugger, with target code only reporting
> architecture-specific debug events and deciding, from architectural state, whether they are eligible for external interception?
>
> The latter seems cleaner to me, especially if the same issue exists for Arm BKPT, RISC-V EBREAK, and breakpoint instructions on other
> architectures.
>
> My current feeling is therefore that the original RFC probably puts the fix too low and too specifically in the Arm code, but that the
> underlying problem remains real: QEMU does not appear to have a clearly defined generic model for what should happen when guest
> code deliberately executes a breakpoint instruction while an external GDB client is attached.
>
> ----
>
> I have tried to summarize the discussion as faithfully as possible, as I was beginning to lose track of the different points and positions.
>
> This leaves me with one final question, which may actually be the key to choosing between the possible models discussed above.
>
> Even if you decide that QEMU's gdbstub should represent an external debugger, what exactly should that imply?
>
> Does attaching a GDB client itself mean that architectural external halting debug is active, so that eligible guest breakpoint instructions
> should naturally be consumed by the external debugger?
>
> Or does it only mean that an external debugger is available, while actual interception must still depend on the architectural debug
> state, such as DHCSR.C_DEBUGEN and the relevant architecture-specific configuration?
>
> My original patch implicitly assumes the first model:
>
> GDB attached
>     => external halting debug active
>     => M-profile BKPT is reported to GDB
>
> But the discussion around DHCSR, DEMCR, self-hosted debugging, and the role of the gdbstub suggests that this equivalence may be
> exactly what needs to be decided first.
>
> Perhaps answering this question would also tell us where the abstraction should live: either directly in target-specific exception
> handling, or in a more generic QEMU external-debug layer with
> architecture-specific eligibility rules.

I think if the gdbstub is going to intercept what would otherwise be
guest visible exceptions then that should be opt-in behaviour via some
sort of flag for gdbstub. Otherwise guests will get confused when they
miss them. For example we know Windows uses breakpoints during its
boot-up for some sort of internal book keeping.

While giving the option to intercept guest visible exceptions in gdbstub
could be done globally if we want to properly model the external debug
interface we probably need to come up with some new API's between
gdbstub and the guest architecture.

For example on ARM the guest can make changes to register state to limit
what the external debugger can do. I see arm_debug_check_breakpoints
does call arm_generate_debug_exceptions which takes into account the
state of OSLAR_EL1. Would anyone actually want to model
DBGAUTHSTATUS_EL1 which can limit which worlds the debugger can see?
Generally the big benefit of using gdbstub with emulation is you do get
full visibility of the system which is helpful when debugging low level
code. Also most of this stuff seems to be very IMPDEF which is not
normally something QEMU needs to worry about.


>
> Have I missed an important case or misunderstood the emerging consensus here?
>
> Thanks again for the discussion,

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro