This lab explores how breakpoints work. Since some assembly is required, we will use MARS to simulate MIPS, since most of you are familiar with it.
Complete the question sheet as you complete the lab.
Check your repos for
mips-breakpoints. Inside will be several files:
music.asm: The music file from the installation instructions
exception.s: An exception handler with support for breakpoints
bp_test.asm: A small piece of code for testing breakpoints
breakpoints.s: A template file for setting breakpoints
For this project, you will need these settings in MARS:
- Unset Settings > Assemble all files in directory
- Unset Settings > Initialize Program counter to global 'main' if defined
- Set Settings > Self-modifying code
- Set Settings > Permit extended (pseudo) instructions and formats
- Use Settings > Exception Handler ...
- Select the
exception.sfile in the
- Select the
bp_test.asm. Look over the code.
breakpoints.s. Let's add a breakpoint. Insert this code:
la $a0 main addi $a0 $a0 4 jal set_bp
This should set a breakpoint at the second instruction past
main. Note that there is a lot of startup code and
mainshould be located at 0x004000b8.
Assemble the code in
bp_test.asm. Run the code.
The simulator should print a message that the breakpoint was hit. Verify that the breakpoint was at the correct instruction location.
Add breakpoints for lines 11, 18, and 25. Note that pseudo instructions might change where these are in memory!
- Run the code
- The breakpoint code is a bit complex. There are three main breakpoint sections: installation, handle breakpoint hits, and restore breakpoints.
- Lines ~483-520 is the code that installs breakpoints. This backups the original instructions, replaces the instruction with the
breakinstruction, and marks the breakpoint as active.
- How many breakpoints does the code support?
- What data is saved for each breakpoint?
- Describe a way to support an effectively unlimited number of breakpoints.
- Lines ~238-436 is the main breakpoint handler. It prints a breakpoint message, inserts another breakpoint after this one, repalces the causing breakpoint with the original instruction, and retries.
- You can make execution pause on breakpoints using the code near line 276.
- Most of the code is taken up by creating the restore breakpoint. Why is this so complex?
- Can software or hardware changes make this less complex?
- Lines ~217-236 is the restore breakpoint handler. This happens after the main breakpoint. This handler puts the original breakpoint back, so it can be hit again if the code reruns.
- Aside from repairing the first breakpoint, what other main action does this code do?
- Close all other code files.
- Run it without breakpoints first and observe the results in the I/O pane and the sound.
breakpoint.sagain and set a breakpoint at the first
la $a0, stanza1in
- It might be helpful to enable the pause feature of the breakpoint handler.
- What has already happened in the program?
- Remove the other breakpoint and set a breakpoint at the first line of
- How many times is the breakpoint hit?
- Remove the other breakpoint and set a breakpoint at the first lines of both
- If you're using pauses, you will definitely want to disable them for this one.
- Which of these two functions is called first?