Invalided cache for breakpoints

[oferShinaar]

Hi Tim,
Do we have, or are we planning to have, CBO operation for cache lines within openocd?
When putting BP's in the memory on a system with multi-level cache we need to invalidate the cache lines so BP will land in cache (i$ in this example)

Thanks,
Ofer

[TommyMurphyTM1234]

Perhaps this is relevant in the context of this question?

• How to ensure consistency between icache and dcache when setting breakpoints #983 (comment)

[oferShinaar]

Yes, Tim's points are correct (on the link you shared). But is there a plan on doing it on the openocd code?

A long time ago we did that here: chipsalliance/Cores-VeeR-EH1#28 (comment)
That was a nice solution when you have only one level of cache and one core. fence.i was good enough.

It becomes tricky when you have multi core/multi level cache levels. Those system have to use cbo on the driver side.
The options (as I see it, please correct me otherwise): 1) Change the openocd that when BP is writing do cbo.flush + reg 2)do it via event on the cfg file, check the PC that GDB is going to put BP into, allocate register for the PC address ( for cbo.flush usage), do the cbo.flush and restore the allocated reg.

[TommyMurphyTM1234]

Just to clarify, does this issue apply specifically to software breakpoints (where the breakpoint instruction is temporarily overwritten with an ebreak instruction) but not trigger based hardware breakpoints? In which case another option might be to not change anything in OpenOCD but to use trigger based hardware breakpoints when (multi-level) instruction caches are present?

Those system have to use cbo on the driver side.

What do you mean by "on the driver side" here? I presume you mean in the OpenOCD RISC-V target specific code?

[oferShinaar]

Yes, only SW BP. Sorry forgot to mention that. HW BPs are expansive and "resource-limited." Yes, "on the driver side" is the "OpenOCD RISC-V target-specific code". need to track the PC that is going to be modified due to `ebrake`

…

On Wed, Aug 14, 2024 at 5:21 PM Tommy Murphy ***@***.***> wrote: Just to clarify, does this issue apply specifically to software breakpoints (where the breakpoint instruction is temporarily overwritten with an ebreak instruction) but not trigger based hardware breakpoints? In which case another option might be to not change anything in OpenOCD but to use trigger based hardware breakpoints when (multi-level) instruction caches are present? Those system have to use cbo on the driver side. What do you mean by "on the driver side" here? I presume you mean in the OpenOCD RISC-V target specific code? — Reply to this email directly, view it on GitHub <#1113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJTYBZM2OCRGCEVP6YNPROLZRNRX5AVCNFSM6AAAAABMQLRFX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBYHEYTSNRXGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[en-sc]

Do we have, or are we planning to have, CBO operation for cache lines within openocd?

IMHO, this would be great. However, I'm not aware of anybody working on this right now.