make check in the
proj-pregame/src/userprog directory, and observe that currently no tests pass. 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.
We are using
do-nothing because it is the simplest test of Pintos’s user program support. You should read
proj-pregame/src/tests/userprog/do-nothing.c; it is a Pintos user application that does nothing. Its main function is merely the statement
return 162, indicating that it 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
do-nothing.c was compiled to create an executable program
do-nothing, which you can find at
do-nothing test simply runs the
do-nothing executable in Pintos.
View the file
proj-pregame/src/userprog/build/tests/userprog/do-nothing.result. 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 (you’ll encounter this again in Project Userprog). 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 contents of the
do-nothing.result file, please answer the following questions on Gradescope:
What virtual address did the program try to access from userspace that caused it to crash?
What is the virtual address of the instruction that resulted in the crash?
To investigate, disassemble the
objdump(you used this tool in Homework 0). What is the name of the function the program was in when it crashed? Copy the disassembled code for that function onto Gradescope, 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.cor one of the files in
proj-pregame/src/lib/user), and copy it onto Gradescope. For each instruction in the disassembled function in #3, explain in a few words why it’s necessary and/or what it’s trying to do. Hint: read about 80x86 calling convention.
Why did the instruction you identified in #3 try to access memory at the virtual address you identified in #1? Don’t explain this in terms of the values of registers; we’re looking for a higher-level explanation