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