search

riscv-collab / riscv-openocd

Fork of OpenOCD that has RISC-V support
Other
441 stars 319 forks source link

Invalided cache for breakpoints #1113

Open oferShinaar opened 1 month ago

oferShinaar commented 1 month ago

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 commented 1 month ago

Perhaps this is relevant in the context of this question?

oferShinaar commented 1 month ago

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: https://github.com/chipsalliance/Cores-VeeR-EH1/issues/28#issuecomment-696587882 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 commented 1 month ago

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 commented 1 month ago

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 https://github.com/riscv-collab/riscv-openocd/issues/1113#issuecomment-2288919670, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJTYBZM2OCRGCEVP6YNPROLZRNRX5AVCNFSM6AAAAABMQLRFX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBYHEYTSNRXGA . You are receiving this because you authored the thread.Message ID: @.***>

en-sc commented 1 month ago

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.