Breakpoint and watchpoint hardware in ARM Architecture - Step-by-Step Execution

Concept Flow - Breakpoint and watchpoint hardware

Program Running

↓

CPU Executes Instruction

↓

Check Breakpoint?

No→Continue Execution

Yes↓

Pause Execution

↓

Debugger Handles Breakpoint

↓

Resume or Step Execution

↓

Memory Access

↓

Check Watchpoint?

No→Continue Execution

Yes↓

Pause Execution

↓

Debugger Handles Watchpoint

↓

Resume or Step Execution

The CPU runs instructions and checks if a breakpoint or watchpoint is hit. If yes, it pauses and lets the debugger handle it before resuming.

Execution Sample

ARM Architecture

1. Set breakpoint at address 0x1000
2. Run program
3. CPU executes instructions
4. When PC == 0x1000, pause
5. Debugger inspects state
6. Resume execution

This sequence shows how a breakpoint pauses program execution when the CPU reaches a specific instruction address.

Analysis Table

Step	CPU Action	PC (Program Counter)	Breakpoint Hit?	Watchpoint Hit?	Debugger Action	Execution State
1	Start program	0x0FFC	No	No	None	Running
2	Execute instruction	0x0FFD	No	No	None	Running
3	Execute instruction	0x0FFE	No	No	None	Running
4	Execute instruction	0x0FFF	No	No	None	Running
5	Execute instruction	0x1000	Yes	No	Pause and notify debugger	Paused
6	Debugger inspects registers	0x1000	Yes	No	Inspect state	Paused
7	Resume execution	0x1001	No	No	Resume	Running
8	Execute instruction	0x1001	No	No	None	Running
9	Memory write to 0x2000	0x1002	No	Yes	Pause and notify debugger	Paused
10	Debugger inspects memory	0x1002	No	Yes	Inspect memory	Paused
11	Resume execution	0x1002	No	No	Resume	Running
12	Execute instruction	0x1003	No	No	None	Running
13	End of trace	0x1003	No	No	None	Running

💡 Execution stops because the trace ends after step 13.

State Tracker

Variable	Start	After Step 5	After Step 7	After Step 9	After Step 11	Final
PC	0x0FFC	0x1000	0x1001	0x1002	0x1002	0x1003
Execution State	Running	Paused	Running	Paused	Running	Running
Breakpoint Hit	No	Yes	No	No	No	No
Watchpoint Hit	No	No	No	Yes	No	No

Key Insights - 3 Insights

Why does the CPU pause at step 5 even though it is just executing an instruction?

Because the program counter (PC) reached the breakpoint address 0x1000, triggering the breakpoint hardware to pause execution as shown in execution_table row 5.

What causes the CPU to pause at step 9 if it is not at a breakpoint?

At step 9, a memory write occurs at address 0x2000 which matches a watchpoint condition, causing the CPU to pause as shown in execution_table row 9.

Does the CPU stay paused after the debugger inspects the state?

No, after inspection (steps 6 and 10), the debugger resumes execution, changing the state back to running as seen in steps 7 and 11.

Visual Quiz - 3 Questions

Look at the execution_table at step 5. What is the value of the PC and what happens?

A PC is 0x1000 and CPU pauses due to breakpoint

B PC is 0x0FFF and CPU continues running

C PC is 0x1001 and CPU pauses due to watchpoint

D PC is 0x1000 and CPU continues running

💡 Hint

Check the 'PC' and 'Breakpoint Hit?' columns at step 5 in execution_table.

At which step does the watchpoint cause the CPU to pause?

A Step 5

B Step 7

C Step 9

D Step 3

💡 Hint

Look at the 'Watchpoint Hit?' column in execution_table to find when it changes to Yes.

If the breakpoint was removed, what would happen at step 5?

A CPU would pause anyway

B CPU would continue running without pause

C CPU would pause due to watchpoint

D CPU would crash

💡 Hint

Refer to execution_table row 5 where breakpoint causes pause; without it, no pause occurs.

Concept Snapshot

Breakpoint and watchpoint hardware let the CPU pause execution when specific instructions or memory accesses happen.
Breakpoints pause on instruction addresses.
Watchpoints pause on memory reads/writes.
Debugger uses these to inspect and control program flow.
CPU resumes after debugger actions.

Full Transcript

This visual execution trace shows how breakpoint and watchpoint hardware work in an ARM CPU. The CPU runs instructions and checks if the current instruction address matches a breakpoint. If yes, it pauses and lets the debugger inspect the program state. Similarly, if a memory access matches a watchpoint, the CPU pauses for debugger inspection. After inspection, the debugger resumes execution. The trace shows the program counter (PC), whether breakpoints or watchpoints are hit, and the CPU execution state step-by-step. This helps beginners see exactly when and why the CPU pauses during debugging.

Practice

1. What is the primary purpose of a breakpoint in ARM architecture debugging?

easy

A. To speed up program execution

B. To monitor changes in memory values

C. To pause program execution at a specific instruction

D. To permanently stop the program

Solution

1. Step 1: Understand the role of breakpoints

   Breakpoints are used to pause the program when it reaches a certain instruction, allowing inspection of program state.

2. Step 2: Differentiate from watchpoints

   Watchpoints pause execution when a specific memory location changes, not at an instruction.

3. Final Answer:

   To pause program execution at a specific instruction -> Option C

4. Quick Check:

   Breakpoint = pause at instruction [OK]

Hint: Breakpoints stop at code lines, watchpoints stop on data changes [OK]

Common Mistakes:

• Confusing breakpoints with watchpoints
• Thinking breakpoints monitor memory changes
• Believing breakpoints speed up execution

2. Which of the following is the correct way to set a hardware watchpoint in ARM debugging?

easy

A. Set a breakpoint at the instruction address

B. Insert a software interrupt instruction

C. Enable the program counter to stop on every instruction

D. Configure the watchpoint register with the memory address to monitor

Solution

1. Step 1: Identify how watchpoints work

   Watchpoints monitor specific memory addresses for changes by configuring hardware registers.

2. Step 2: Recognize correct setup

   Setting the watchpoint register with the memory address to watch is the correct method.

3. Final Answer:

   Configure the watchpoint register with the memory address to monitor -> Option D

4. Quick Check:

   Watchpoint = monitor memory address [OK]

Hint: Watchpoints need memory address setup, not instruction address [OK]

Common Mistakes:

• Confusing breakpoints with watchpoints
• Trying to set watchpoints at instruction addresses
• Using software interrupts instead of hardware registers

3. Consider this scenario: A watchpoint is set on memory address 0x2000. Which event will cause the program to pause?

medium

A. When the value at memory address 0x2000 is written or changed

B. When the value at memory address 0x2000 is read

C. When the instruction at address 0x2000 is executed

D. When the program counter reaches 0x2000

Solution

1. Step 1: Understand watchpoint triggers

   Watchpoints pause execution when the watched memory location is written to or changed, not just read or executed.

2. Step 2: Analyze each option

   Instruction execution or program counter reaching 0x2000 would trigger a breakpoint, not a watchpoint. Reading the value at 0x2000 usually does not trigger a watchpoint. Writing or changing the value at 0x2000 is the event that causes the pause.

3. Final Answer:

   When the value at memory address 0x2000 is written or changed -> Option A

4. Quick Check:

   Watchpoint triggers on memory write/change [OK]

Hint: Watchpoints pause on memory writes, not reads or instruction execution [OK]

Common Mistakes:

• Thinking watchpoints trigger on memory reads
• Confusing instruction address with memory address
• Assuming program counter triggers watchpoints

4. A developer sets a hardware breakpoint at instruction address 0x1004 but the program does not stop there during debugging. What could be the likely cause?

medium

A. The instruction at 0x1004 is never executed

B. The breakpoint was set on a memory address instead of an instruction address

C. The watchpoint register was incorrectly configured

D. The program counter is disabled

Solution

1. Step 1: Verify breakpoint conditions

   A breakpoint only pauses execution if the program actually reaches the instruction address where it is set.

2. Step 2: Analyze possible causes

   Since the scenario specifies setting a hardware breakpoint at an instruction address 0x1004, issues like setting it on a memory address or misconfiguring watchpoint registers do not apply. The program will not pause if that instruction is never executed during program flow.

3. Final Answer:

   The instruction at 0x1004 is never executed -> Option A

4. Quick Check:

   Breakpoint triggers only if instruction runs [OK]

Hint: Breakpoint triggers only if code runs that instruction [OK]

Common Mistakes:

• Confusing breakpoint and watchpoint setup
• Assuming breakpoint triggers without execution
• Ignoring program flow and instruction reachability

5. You want to debug a program that sometimes corrupts a variable stored at memory address 0x3000. Which hardware debugging method should you use to catch the exact moment the variable changes, and why?

hard

A. Set a breakpoint at the instruction that writes to 0x3000 to pause execution there

B. Set a watchpoint on memory address 0x3000 to pause when its value changes

C. Set a breakpoint on the program counter to stop every instruction

D. Use a software interrupt to halt the program periodically

Solution

1. Step 1: Identify the debugging goal

   The goal is to catch the exact moment a variable at a specific memory address changes.

2. Step 2: Choose the appropriate hardware method

   A watchpoint monitors memory address changes directly, pausing execution immediately when the variable changes. Breakpoints pause at instructions but require knowing the exact instruction, which may be complex or unknown.

3. Final Answer:

   Set a watchpoint on memory address 0x3000 to pause when its value changes -> Option B

4. Quick Check:

   Watchpoint = pause on memory change [OK]

Hint: Use watchpoints to catch variable changes without guessing instructions [OK]

Common Mistakes:

• Using breakpoints without knowing exact instruction
• Stopping every instruction wastes time
• Relying on software interrupts instead of hardware watchpoints