are quite likely, and you should seriously consider both. We hope
that the third is less likely, but it is also possible.
+@anchor{Debugging User Programs}
You can also use @command{gdb} to debug a user program running under
Pintos. Start by issuing this @command{gdb} command to load the
program's symbol table:
implement some of them in project 3 and the rest in project 4, so be
sure to design your system with extensibility in mind.
-To implement syscalls, you need to provide ways to copy data
-from user virtual address space into the kernel and vice versa.
+To implement syscalls, you need to provide ways to read and write data
+in user virtual address space.
You need this ability before you can
even obtain the system call number, because the system call number is
on the user's stack in the user's virtual address space.
This can be a bit tricky: what if the user provides an invalid
pointer, a pointer into kernel memory, or a block
partially in one of those regions? You should handle these cases by
-terminating the user process. We recommend
+terminating the user process. We recommend
writing and testing this code before implementing any other system
call functionality.
Modify @file{src/examples/Makefile}, then run @command{make}.
+@item Can I run user programs under a debugger?
+
+Yes, with some limitations. @xref{Debugging User Programs}.
+
@item What's the difference between @code{tid_t} and @code{pid_t}?
A @code{tid_t} identifies a kernel thread, which may have a user