Re: [PATCH v11 4/5] xen/riscv: enable GENERIC_BUG_FRAME

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.08.2024 11:14, oleksii.kurochko@xxxxxxxxx wrote:
> On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
>>> To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
>>> it is needed to enable GENERIC_BUG_FRAME.
>>>
>>> ebreak is used as BUG_insn so when macros from <xen/bug.h> are
>>> used, an exception with BREAKPOINT cause will be generated.
>>>
>>> ebreak triggers a debug trap, which starts in debug mode and is
>>> then filtered by every mode. A debugger will first handle the
>>> debug trap and check if ebreak was set by it or not. If not,
>>> CAUSE_BREAKPOINT will be generated for the mode where the ebreak
>>> instruction was executed.
>>
>> Here and in the similar code comment you talk about an external
>> debugger, requiring debug mode, which is an optional feature. In
>> my earlier comments what I was referring to was pure software
>> debugging. I continue to fail to see how properly distinguishing
>> ebreak uses for breakpoints from ebreak uses for e.g. BUG() and
>> WARN() is going to be feasible.
> GDB keeps track of what addresses it has breakpoints at.

Of course it does. But in Xen how do you decide whether to trigger
the debugger when you've hit an ebreak? (Just to repeat, my question
is about the purely software debugging case; no hardware debugging
extensions. In such a case, aiui, Xen gains control first and then
decides whether to trigger the debugger, or whether to handle the
exception internally. Sure, none of this infrastructure is in place
right now, but imo it wants taking into consideration.)

> And if QEMU is being used, GDB isn't actually inserting ebreak
> instructions because QEMU has an infinite amount of "hardware"
> breakpoints.
> 
> If it answers your original question I could add this to commit
> message/code in the next patch version.

I'm afraid it still doesn't.

Jan