Find the faulting Instruction

First, run make and make check in the src/userprog directory. For this project, we have enabled two tests do-nothing and stack-align-0 and you will see that both of them fail.

For this assignment, we will step through the execution of the do-nothing test in GDB to learn how we can modify PintOS so that the test passes, and understand how PintOS’s existing support for user programs is implemented. You can find this test under the src/tests/userprog directory.

do-nothing is the simplest test of PintOS’s user program support. Take a look at src/tests/userprog/do-nothing.c; it is a PintOS user application that does nothing. The single return 162 statement in the main function returns the exit code 162 to the operating system. The specific value of the exit code is immaterial to the test; we chose a value other than 0 so that it’s easier to track how the PintOS kernel handles this value through GDB (note 162 = 0xa2).

When you ran make, do-nothing.c was compiled to create an executable program do-nothing, which you can find at src/userprog/build/tests/userprog/do-nothing. The do-nothing test simply runs the do-nothing executable in PintOS.

View the file src/userprog/build/tests/userprog/do-nothing.result. (Alternatively to make check, you may also run pintos-test do-nothing in the terminal.) This file shows the output of the PintOS testing framework when running the do-nothing test. The testing framework expected PintOS to output do-nothing: exit(162). This is the standard message that PintOS prints when a process exits. However, as shown in the diff, PintOS did not output this message; instead, the do-nothing program crashed in userspace due to a memory access violation (a segmentation fault). Based on the output of the do-nothing test, please answer the following questions in results/answers.md:

Q1: What virtual address did the program try to access from userspace that caused it to crash? Why is the program not allowed to access this memory address at this point?

Q2: What is the virtual address of the instruction that resulted in the crash?

To investigate, disassemble the do-nothing binary using objdump (you used this tool in Assignment 0).

Q3: What is the name of the function the program was in when it crashed? Copy the disassembled code for that function into answers.md, and identify the instruction at which the program crashed.

Find the C code for the function you identified above (Hint: it was executed in userspace, so it’s either in do-nothing.c or one of the files in src/lib or src/lib/user), and copy it into answers.md.

Q4: For each instruction in the disassembled function in Q3, explain in a few words why it’s necessary and/or what it’s trying to do. Hint: read about und understand 80x86 calling convention.

Q5: Why did the instruction you identified in Q3 try to access memory at the virtual address you identified in Q1? Please provide a high-level explanation, rather than simply mentioning register values.

Next step: Step through the Crash.