openocd-devel

proposal: automatically resume rogue breakpoints

[Liviu I. <il...@li...>]

Given the findings discussed in a previous thread, it seems that the existing Cortex-M7 cores from STM have a bug which triggers an unexpected breakpoint when a valid breakpoint occurs within a short time window after pending an interrupt.

When running in a debug session, such a rogue breakpoint halts the core in the debugger as usual, and execution can be manually resumed.

However, when running as an unmanned standalone semihosted unit tests, execution halts and it is not possible to resume it; thus the test hangs.

Attempts to find a workaround by masking interrupts via `cortex_m maskisr on` failed, since this interferes with the application interrupts.

I suggest to address the issue by a patch in the OpenOCD source code, to automatically resume breakpoints at addresses that are not registered as a hardware (FPB) breakpoint (and eventually leave a line in the log).


For cores that are not affected by this bug, this change should be harmless; for those affected, it would make the unmanned unit-tests pass and also reduce the annoyance during debug sessions.


Liviu

Re: proposal: automatically resume rogue breakpoints

[Tim N. <ti...@si...>]

As long as this is limited to cores that are known to maybe have such a
bug, it doesn't affect me. In general I don't think OpenOCD can always know
whether a halt is caused by a bug or not. Cross triggering is a good
example of that, but even delayed memory access breakpoints are hard to
match up, unless the hardware explicitly tells you the reason.

Tim

On Sat, Jul 22, 2023 at 12:07 AM Liviu Ionescu <il...@li...> wrote:

> Given the findings discussed in a previous thread, it seems that the
> existing Cortex-M7 cores from STM have a bug which triggers an unexpected
> breakpoint when a valid breakpoint occurs within a short time window after
> pending an interrupt.
>
> When running in a debug session, such a rogue breakpoint halts the core in
> the debugger as usual, and execution can be manually resumed.
>
> However, when running as an unmanned standalone semihosted unit tests,
> execution halts and it is not possible to resume it; thus the test hangs.
>
> Attempts to find a workaround by masking interrupts via `cortex_m maskisr
> on` failed, since this interferes with the application interrupts.
>
> I suggest to address the issue by a patch in the OpenOCD source code, to
> automatically resume breakpoints at addresses that are not registered as a
> hardware (FPB) breakpoint (and eventually leave a line in the log).
>
>
> For cores that are not affected by this bug, this change should be
> harmless; for those affected, it would make the unmanned unit-tests pass
> and also reduce the annoyance during debug sessions.
>
>
> Liviu
>
>
>
>
>
>
>
>
>
>

Re: proposal: automatically resume rogue breakpoints

[Liviu I. <il...@li...>]

> On 24 Jul 2023, at 18:57, Tim Newsome <ti...@si...> wrote:
> 
> As long as this is limited to cores that are known to maybe have such a bug

The proposal obviously apply to architectures that can identify legit breakpoints.

In particular, for Cortex-M cores, that implement that set of FPB registers storing breakpoint addresses, assuming that OpenOCD can read them.

All other architectures/cores can simply halt at the breakpoint, as they do now.

If necessary, this new behaviour can be enabled by a configuration option.


Liviu

Re: proposal: automatically resume rogue breakpoints

[Christopher H. <op...@ch...>]

On July 24, 2023 9:50:54 a.m. PDT, Liviu Ionescu <il...@li...> wrote:
>If necessary, this new behaviour can be enabled by a configuration
>option.

I don’t mind if a config option is added, but I am strongly opposed to
this being mandatory behaviour. It would break the use case of
compiling BKPT instructions into the binary for non-semihosting
purposes, because such halts would not match any FPB resource. I use
that capability regularly as a way to debug halt on certain error
conditions detected by the code, without spending FPB resources to do
so.

-- 
Christopher Head

Re: proposal: automatically resume rogue breakpoints

[Liviu I. <il...@li...>]

> On 26 Jul 2023, at 07:43, Christopher Head <op...@ch...> wrote:
> 
> ... I am strongly opposed to
> this being mandatory behaviour. It would break the use case of
> compiling BKPT instructions into the binary for non-semihosting
> purposes, because such halts would not match any FPB resource.

Ah, sorry for not being more explicit, the proposal covers only rogue breakpoints, it does not cover compiled BKPT instructions, since these are legit breakpoints.

> I use
> that capability regularly as a way to debug halt on certain error
> conditions detected by the code, without spending FPB resources to do
> so.

I also use this, with DEBUG defined, my code halts with BKPT(0) whenever any asserts trigger.

---

BTW, the behaviour of OpenOCD when encountering BKPT instructions is debatable.

If OpenOCD is in a debug session, execution should indeed halt, as it does now, but when running in standalone mode, (for example with no connection on the gdb port), a more accurate behaviour would be to trigger an exception, as defined by the architecture when not in debug state (for example DebugMon_Handler for ARMv7M).


Liviu

Re: proposal: automatically resume rogue breakpoints

[Liviu I. <il...@li...>]

> On 26 Jul 2023, at 08:28, Liviu Ionescu <il...@li...> wrote:
> 
> a more accurate behaviour would be to trigger an exception, as defined by the architecture

Except, of course, semihosting BKPTs, when semihosting is explicitly enabled.

Liviu

Re: proposal: automatically resume rogue breakpoints

[Tommy M. <tom...@ho...>]

Hi Liviu - could you perhaps clarify - maybe in pseudo code - what you mean by a "rogue breakpoint"? The exact nature of what you mean by this is still unclear to me.
________________________________
From: Liviu Ionescu <il...@li...>
Sent: Wednesday, July 26, 2023 6:47:54 AM
To: Christopher Head <op...@ch...>
Cc: ope...@li... <ope...@li...>
Subject: Re: proposal: automatically resume rogue breakpoints



> On 26 Jul 2023, at 08:28, Liviu Ionescu <il...@li...> wrote:
>
> a more accurate behaviour would be to trigger an exception, as defined by the architecture

Except, of course, semihosting BKPTs, when semihosting is explicitly enabled.

Liviu

Re: proposal: automatically resume rogue breakpoints

[Liviu I. <il...@li...>]

> On 26 Jul 2023, at 12:47, Tommy Murphy <tom...@ho...> wrote:
> 
> Hi Liviu - could you perhaps clarify - maybe in pseudo code - what you mean by a "rogue breakpoint"? The exact nature of what you mean by this is still unclear to me. 

If the source of the breakpoint cannot be identified, it is probably not legit.

BKPT instructions can obviously be identified, thus are legit.

Breakpoints triggered by matched conditions (like the FPB registers) are also legit.

If no such known condition can be identified and checked by OpenOCD, the breakpoint is probably rogue, and, at least when not in a debug session, can/should be resumed.

I agree that this is not a normal condition, but a safety net for buggy cores, like Cortex-M7.

Without such a workaround, using OpenOCD for running standalone semihosted unit-tests on STM32F7 & H7 is currently not possible; for me, this is an annoying setback, I have to limit myself to STM32F4.


Liviu