sid/renode-m68hc12
1
0
Fork 0
Code Issues 6 Pull requests 1 Projects Releases Packages Wiki Activity Actions

No debug hooks (AddHook, breakpoints, watchpoints throw) #5

New issue
Open
opened 2026-08-24 11:43:36 +02:00 by sid · 0 comments
sid commented 2026-08-24 11:43:36 +02:00
Owner
Copy link

Summary

All of the BaseCPU debug-hook APIs throw RecoverableException("This feature is not implemented yet") (M68HC12.cs:146-184):

  • AddHookAtInterruptBegin / AddHookAtInterruptEnd
  • AddHookAtWfiStateChange
  • AddHook
  • RemoveHook
  • RemoveHooksAt
  • RemoveHooks
  • RemoveAllHooks

Impact

Because AddHook(ulong, CpuAddressHook) is what the Renode monitor uses to
implement address breakpoints and watchpoints, none of these work for the
m68hc12 CPU:

  • cpu AddHook 0x... / monitor breakpoint commands throw.
  • Per-address trace hooks (cpu AddHook ... "LogRegisters" etc.) are
    unavailable.
  • Interrupt-entry/exit and WFI/WAI-state trace hooks are unavailable.

This is the standard debugging surface every other Renode CPU exposes; its
absence makes the port hard to use for interactive firmware bring-up.

Current behavior

Every hook method unconditionally throws. The CPU is otherwise fully wired into
Renode (GDB server, stepping, register access all work), so the gap is isolated
to the hook plumbing.

Affected files

  • src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12.cs:146-184
  • Add tests alongside src/Infrastructure/src/Emulator/Main/Tests/UnitTests/M68HC12GdbTests.cs

Desired behavior

Implement the hook semantics, matching how other pure-C# interpreter CPUs in
Renode do it (the MSP430X or the ARM translator's BPU, or a simpler
interpreter that stores a dictionary of ulong → CpuAddressHook):

  • AddHook(addr, hook) registers a hook fired when the PC equals addr.
  • RemoveHook / RemoveHooksAt / RemoveAllHooks manage them correctly.
  • AddHookAtInterruptBegin/End fire on interrupt entry/return.
  • AddHookAtWfiStateChange fires when WAI/STOP state changes.

The natural hook point is the ExecuteInstructions loop (M68HC12.cs:49-70)
and HandleInterrupts/HandleInterrupt (M68HC12.cs:631-677), checking the
PC against registered hooks before dispatching each instruction.

Acceptance criteria

  • cpu AddHook 0x... succeeds and fires at the right address (verified via a
    hook that logs or changes state, and via the monitor).
  • Breakpoint halt + continue round-trips work from the monitor.
  • RemoveHook/RemoveHooksAt/RemoveAllHooks behave correctly.
  • WAI/STOP state-change and interrupt hooks fire as documented.
  • Unit tests cover add/fire/remove semantics; no existing tests regress.

Suggested approach

  • Look at how the MSP430X interpreter (the model for this port) implements
    AddHook and reuse that pattern verbatim where license-compatible.
  • Run the monitor/Robot-level check to confirm cpu AddHook no longer throws.
## Summary All of the `BaseCPU` debug-hook APIs throw `RecoverableException("This feature is not implemented yet")` (`M68HC12.cs:146-184`): - `AddHookAtInterruptBegin` / `AddHookAtInterruptEnd` - `AddHookAtWfiStateChange` - `AddHook` - `RemoveHook` - `RemoveHooksAt` - `RemoveHooks` - `RemoveAllHooks` ## Impact Because `AddHook(ulong, CpuAddressHook)` is what the Renode monitor uses to implement address breakpoints and watchpoints, **none of these work for the m68hc12 CPU**: - `cpu AddHook 0x...` / monitor `breakpoint` commands throw. - Per-address trace hooks (`cpu AddHook ... "LogRegisters"` etc.) are unavailable. - Interrupt-entry/exit and WFI/WAI-state trace hooks are unavailable. This is the standard debugging surface every other Renode CPU exposes; its absence makes the port hard to use for interactive firmware bring-up. ## Current behavior Every hook method unconditionally throws. The CPU is otherwise fully wired into Renode (GDB server, stepping, register access all work), so the gap is isolated to the hook plumbing. ## Affected files - `src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12.cs:146-184` - Add tests alongside `src/Infrastructure/src/Emulator/Main/Tests/UnitTests/M68HC12GdbTests.cs` ## Desired behavior Implement the hook semantics, matching how other pure-C# interpreter CPUs in Renode do it (the MSP430X or the ARM translator's BPU, or a simpler interpreter that stores a dictionary of `ulong → CpuAddressHook`): - `AddHook(addr, hook)` registers a hook fired when the PC equals `addr`. - `RemoveHook` / `RemoveHooksAt` / `RemoveAllHooks` manage them correctly. - `AddHookAtInterruptBegin/End` fire on interrupt entry/return. - `AddHookAtWfiStateChange` fires when `WAI`/`STOP` state changes. The natural hook point is the `ExecuteInstructions` loop (`M68HC12.cs:49-70`) and `HandleInterrupts`/`HandleInterrupt` (`M68HC12.cs:631-677`), checking the PC against registered hooks before dispatching each instruction. ## Acceptance criteria - `cpu AddHook 0x...` succeeds and fires at the right address (verified via a hook that logs or changes state, and via the monitor). - Breakpoint halt + continue round-trips work from the monitor. - `RemoveHook`/`RemoveHooksAt`/`RemoveAllHooks` behave correctly. - WAI/STOP state-change and interrupt hooks fire as documented. - Unit tests cover add/fire/remove semantics; no existing tests regress. ## Suggested approach - Look at how the MSP430X interpreter (the model for this port) implements `AddHook` and reuse that pattern verbatim where license-compatible. - Run the monitor/Robot-level check to confirm `cpu AddHook` no longer throws.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
upstream
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
sid/renode-m68hc12#5
No description provided.