X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fthreads.texi;h=f219db44fd800b94370d6ad2a978aa36f60517b7;hb=64f0952217e8b1a53461f5a98a070cb2da266171;hp=04d48d1c0eff50c96f56ecdeeb338382f970da5f;hpb=36088b8cdcd561b472b60ae5e9cf7a5fde9132b9;p=pintos-anon

diff --git a/doc/threads.texi b/doc/threads.texi
index 04d48d1..f219db4 100644
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -15,9 +15,8 @@ Before you read the description of this project, you should read all
 of the following sections: @ref{Introduction}, @ref{Coding Standards},
 @ref{Project Documentation}, @ref{Debugging Tools}, and
 @ref{Development Tools}.  You should at least skim the material in
-@ref{Threads Tour}, but there's no need to fret over the details.  To
-complete this project you will also need to read @ref{Multilevel
-Feedback Scheduling}.
+@ref{Threads Tour}.  To complete this project you will also need to
+read @ref{Multilevel Feedback Scheduling}.
 
 @menu
 * Understanding Threads::       
@@ -74,15 +73,21 @@ thread we're switching to.
 Using the @command{gdb} debugger, slowly trace through a context
 switch to see what happens (@pxref{i386-elf-gdb}).  You can set a
 breakpoint on the @func{schedule} function to start out, and then
-single-step from there.  Be sure to keep track of each thread's
-address and state, and what procedures are on the call stack for each
-thread.  You will notice that when one thread calls
-@func{switch_threads}, another thread starts running, and the first
-thing the new thread does is to return from
-@func{switch_threads}.  We realize this comment will seem cryptic to
-you at this point, but you will understand threads once you understand
-why the @func{switch_threads} that gets called is different from the
-@func{switch_threads} that returns.
+single-step from there.@footnote{@command{gdb} might tell you that
+@func{schedule} doesn't exist, which is arguably a @command{gdb} bug.
+You can work around this by setting the breakpoint by filename and
+line number, e.g.@: @code{break thread.c:@var{ln}} where @var{ln} is
+the line number of the first declaration in @func{schedule}.
+Alternatively you can recompile with optimization turned off, by
+removing @samp{-O3} from the @code{CFLAGS} line in
+@file{Make.config}.}  Be sure to keep track of each thread's address
+and state, and what procedures are on the call stack for each thread.
+You will notice that when one thread calls @func{switch_threads},
+another thread starts running, and the first thing the new thread does
+is to return from @func{switch_threads}.  We realize this comment will
+seem cryptic to you at this point, but you will understand threads
+once you understand why the @func{switch_threads} that gets called is
+different from the @func{switch_threads} that returns.
 
 @strong{Warning}: In Pintos, each thread is assigned a small,
 fixed-size execution stack just under @w{4 kB} in size.  The kernel
@@ -131,7 +136,7 @@ gets initialized.
 @item thread.c
 @itemx thread.h
 Basic thread support.  Much of your work will take place in these
-files.  @file{thread.h} defines @code{struct thread}, which you will
+files.  @file{thread.h} defines @struct{thread}, which you will
 modify in the first three projects.
 
 @item switch.S
@@ -407,7 +412,7 @@ should implement @func{thread_join} to have the same restriction.
 That is, a thread may only join its immediate children.
 
 A thread need not ever be joined.  Your solution should properly free
-all of a thread's resources, including its @code{struct thread},
+all of a thread's resources, including its @struct{thread},
 whether it is ever joined or not, and regardless of whether the child
 exits before or after its parent.  That is, a thread should be freed
 exactly once in all cases.