Second batch of corrections for incorrect paths.

BUG=none
R= binji@chromium.org, jfb@chromium.org
TEST=none
NOTRY=true
(documentation only change)

Review URL: https://codereview.chromium.org/488133003

Cr-Commit-Position: refs/heads/master@{#291006}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@291006 0039d316-1c4b-4281-b951-d872f2087c98

13 files changed, 147 insertions, 127 deletions

diff --git a/native_client_sdk/doc_generated/community/index.html b/native_client_sdk/doc_generated/community/index.html
index 6ff7409..e8bb503 100644
--- a/native_client_sdk/doc_generated/community/index.html
+++ b/native_client_sdk/doc_generated/community/index.html
@@ -3,7 +3,7 @@
 <section id="community">
 <span id="id1"></span><h1 id="community"><span id="id1"></span>Community</h1>
 <p>This section contains pages related to the Native Client <em>community</em> - both
-<strong>implementors</strong> (contributors to the <a class="reference external" href="https://code.google.com/p/nativeclient/">open-source Native Client project</a>) and <strong>developers</strong>, who use Native Client to develop web
+<strong>implementors</strong> (contributors to the <a class="reference external" href="nacl_project_">open-source Native Client project</a>) and <strong>developers</strong>, who use Native Client to develop web
 applications.</p>
 <p>For a list of active forums where you can ask questions, check the
 <a class="reference internal" href="/native-client/help.html#help"><em>help page</em></a>.</p>
diff --git a/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html b/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html
index c4503f1..1b2b712 100644
--- a/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html
+++ b/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html
@@ -394,12 +394,12 @@ to avoid client side buffers. Use Vertex Buffer Objects (VBOs) instead.</li>
 to a single point. You could create a buffer and bind it to both
 <code>GL_ARRAY_BUFFER</code> and <code>GL_ELEMENT_ARRAY_BUFFER</code>, but that would be
 expensive overhead and it is not recommended.</li>
-<li><strong>Don&#8217;t call ``glGet*`` or ``glCheck*`` during rendering.</strong> This is normal
+<li><strong>Don&#8217;t call glGet* or glCheck* during rendering.</strong> This is normal
 advice for OpenGL programs, but is particularly important for 3D on
 Chrome. Calls to any OpenGL ES 2.0 function whose name begins with these
 strings blocks the Native Client thread. This includes <code>glGetError</code>; avoid
 calling it in release builds.</li>
-<li><strong>Don&#8217;t use fixed point (``GL_FIXED``) vertex attributes.</strong> Fixed point
+<li><strong>Don&#8217;t use fixed point (GL_FIXED) vertex attributes.</strong> Fixed point
 attributes are not supported in OpenGL ES 2.0, so emulating them in OpenGL ES
 2.0 is slow. By default, <code>GL_FIXED</code> support is turned off in the Pepper 3D
 API.</li>
@@ -408,7 +408,7 @@ API.</li>
 2.0 implementation when you update a portion of a buffer (with
 <code>glSubBufferData</code> for example) the entire buffer must be reprocessed. To
 avoid this problem, keep static and dynamic data in different buffers.</li>
-<li><strong>Don&#8217;t call ``glDisable(GL_TEXTURE_2D)``.</strong> This is an OpenGL ES 2.0
+<li><strong>Don&#8217;t call glDisable(GL_TEXTURE_2D).</strong> This is an OpenGL ES 2.0
 error. Each time it is called, an error messages will appear in Chrome&#8217;s
 <code>about:gpu</code> tab.</li>
 </ul>
diff --git a/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html b/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html
index eb0477b..a429187 100644
--- a/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html
+++ b/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html
@@ -123,9 +123,9 @@ the NaCl SDK), these three components are specified in the file
 <code>hello_tutorial.cc</code>. Here is the factory function:</p>
 <pre class="prettyprint">
 namespace pp {
-Module* CreateModule() {
-  return new HelloTutorialModule();
-}
+  Module* CreateModule() {
+    return new HelloTutorialModule();
+  }
 }
 </pre>
 <p>The <code>CreateModule()</code> factory function is the main binding point between a
diff --git a/native_client_sdk/doc_generated/devguide/coding/progress-events.html b/native_client_sdk/doc_generated/devguide/coding/progress-events.html
index b2a5e57..afca37c 100644
--- a/native_client_sdk/doc_generated/devguide/coding/progress-events.html
+++ b/native_client_sdk/doc_generated/devguide/coding/progress-events.html
@@ -20,8 +20,8 @@ chapter assumes you are familiar with the material presented in the
 <a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a>.</p>
 <aside class="note">
 The load_progress example illustrates progress event handling. You can find
-this code in the <code>/examples/tutorial/load_progress/</code> directory in the Native
-Client SDK download.
+this code in the <code>/pepper_&lt;version&gt;/examples/tutorial/load_progress/</code>
+directory in the Native Client SDK download.
 </aside>
 <h2 id="module-loading-and-progress-events">Module loading and progress events</h2>
 <p>The Native Client runtime reports a set of state changes during the module
diff --git a/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html b/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html
index f311110..fd2daed 100644
--- a/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html
+++ b/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html
@@ -28,12 +28,12 @@ programming techniques. The <code>input_events</code> example is used to
 illustrate how your module can react to keyboard and mouse input
 event.  The <code>mouse_lock</code> example is used to illustrate how your module
 can react to view change events. You can find these examples in the
-<code>/examples/api/input_events</code> and <code>/examples/api/mouse_lock</code>
-directories in the Native Client SDK.  There is also the
-ppapi_simple library that can be used to to implement most of the
-boiler plate.  The <code>pi_generator</code> example in
-<code>/examples/demo/pi_generator</code> uses ppapi_simple to manage view
-change events and 2D graphics.</p>
+<code>/pepper_&lt;version&gt;/examples/api/input_event</code> and
+<code>/pepper_&lt;version&gt;/examples/api/mouse_lock</code> directories in the Native Client
+SDK.  There is also the ppapi_simple library that can be used to to implement
+most of the boiler plate.  The <code>pi_generator</code> example in
+<code>/pepper_&lt;version&gt;/examples/demo/pi_generator</code> uses ppapi_simple to manage
+view change events and 2D graphics.</p>
 <h2 id="overview">Overview</h2>
 <p>When a user interacts with the web page using a keyboard, mouse or some other
 input device, the browser generates input events.  In a traditional web
diff --git a/native_client_sdk/doc_generated/devguide/devcycle/debugging.html b/native_client_sdk/doc_generated/devguide/devcycle/debugging.html
index ddd55f2..3dfbfbf 100644
--- a/native_client_sdk/doc_generated/devguide/devcycle/debugging.html
+++ b/native_client_sdk/doc_generated/devguide/devcycle/debugging.html
@@ -26,7 +26,7 @@ and measure your application&#8217;s performance.</p>
 <li><a class="reference internal" href="#debugging-with-visual-studio" id="id11">Debugging with Visual Studio</a></li>
 <li><p class="first"><a class="reference internal" href="#debugging-with-nacl-gdb" id="id12">Debugging with nacl-gdb</a></p>
 <ul class="small-gap">
-<li><a class="reference internal" href="#debugging-pnacl-pexes-with-pepper-35" id="id13">Debugging PNaCl pexes (with Pepper 35+)</a></li>
+<li><a class="reference internal" href="#debugging-pnacl-pexes-pepper-35-or-later" id="id13">Debugging PNaCl pexes (Pepper 35 or later)</a></li>
 <li><a class="reference internal" href="#debugging-pnacl-pexes-with-older-pepper-toolchains" id="id14">Debugging PNaCl pexes (with older Pepper toolchains)</a></li>
 <li><a class="reference internal" href="#running-nacl-gdb" id="id15">Running nacl-gdb</a></li>
 </ul>
@@ -51,15 +51,15 @@ application:</p>
 memory information are visible. If they are not, right click in the header
 row and select the memory items from the popup menu that appears.</li>
 </ol>
-<p>A browser window running a Native Client application will have at least two
-processes associated with it: a process for the app&#8217;s top level (the render
-process managing the page including its HTML and any JavaScript) and one or
-more processes for each instance of a Native Client module embedded in the page
-(each process running native code from one nexe file). The top-level process
-appears with the application&#8217;s icon and begins with the text &#8220;App:&#8221;. A Native
-Client process appears with a Chrome extension icon (a jigsaw puzzle piece
-<img alt="puzzle" src="/native-client/images/puzzle.png" />) and begins with the text &#8220;Native Client module&#8221; followed by the URL
-of its manifest file.</p>
+<p>A browser window running a Native Client application has at least two processes
+associated with it: a process for the app&#8217;s top level (the render process
+managing the page including its HTML and JavaScript) and one or more
+processes for each instance of a Native Client module embedded in the page
+(each process running native code from one nexe or pexe file). The top-level
+process appears with the application&#8217;s icon and begins with the text &#8220;Tab:&#8221;.
+A Native Client process appears with a Chrome extension icon (a jigsaw puzzle
+piece <img alt="puzzle" src="/native-client/images/puzzle.png" />) and begins with the text &#8220;Native Client module:&#8221; followed by the
+URL of its manifest file.</p>
 <p>From the Task Manager you can view the changing memory allocations of all the
 processes associated with a Native Client application. Each process has its own
 memory footprint. You can also see the rendering rate displayed as frames per
@@ -71,18 +71,17 @@ application process, so look for the rendering rate there.</p>
 increase the amount of Native Client&#8217;s diagnostic output by setting the
 following <a class="reference external" href="http://en.wikipedia.org/wiki/Environment_variable">environment variables</a>:</p>
 <ul class="small-gap">
-<li>NACL_PLUGIN_DEBUG=1</li>
-<li>NACL_SRPC_DEBUG=[1-255] (use a higher number for more verbose debug output)</li>
-<li>NACLVERBOSITY=[1-255]</li>
+<li><code>NACL_PLUGIN_DEBUG=1</code></li>
+<li><code>NACL_SRPC_DEBUG=[1-255]</code> (use a higher number for more verbose debug
+output)</li>
+<li><code>NACLVERBOSITY=[1-255]</code></li>
 </ul>
 <h2 id="basic-debugging">Basic debugging</h2>
 <h3 id="writing-messages-to-the-javascript-console">Writing messages to the JavaScript console</h3>
-<p>You can send messages from your C/C++ code to JavaScript using the PostMessage
-call in the <a class="reference internal" href="/native-client/devguide/coding/message-system.html"><em>Pepper messaging system</em></a>. When the
-JavaScript code receives a message, its message event handler can call
-<a class="reference external" href="https://developer.mozilla.org/en/DOM/console.log">console.log()</a> to write
-the message to the JavaScript <a class="reference external" href="/devtools/docs/console-api">console</a> in
-Chrome&#8217;s Developer Tools.</p>
+<p>You can send messages from your C/C++ code to JavaScript using the
+<code>PostMessage()</code> call in the <a class="reference internal" href="/native-client/devguide/coding/message-system.html"><em>Pepper messaging system</em></a>. When the JavaScript code receives a message, its
+message event handler can call <a class="reference external" href="https://developer.mozilla.org/en/DOM/console.log">console.log()</a> to write the message to the
+JavaScript <a class="reference external" href="/devtools/docs/console-api">console</a> in Chrome&#8217;s Developer Tools.</p>
 <h3 id="debugging-with-printf">Debugging with printf</h3>
 <p>Your C/C++ code can perform inline printf debugging to stdout and stderr by
 calling fprintf() directly, or by using cover functions like these:</p>
@@ -98,7 +97,8 @@ void errormsg(const char* pMsg){
 <p>By default stdout and stderr will appear in Chrome&#8217;s stdout and stderr stream
 but they can also be redirected as described below.</p>
 <h4 id="redirecting-output-to-log-files">Redirecting output to log files</h4>
-<p>You can redirect stdout and stderr to output files by setting these environment variables:</p>
+<p>You can redirect stdout and stderr to output files by setting these environment
+variables:</p>
 <ul class="small-gap">
 <li><code>NACL_EXE_STDOUT=c:\nacl_stdout.log</code></li>
 <li><code>NACL_EXE_STDERR=c:\nacl_stderr.log</code></li>
@@ -111,10 +111,10 @@ variable as follows:</p>
 <li><code>NACLLOG=c:\nacl.log</code></li>
 </ul>
 <aside class="note">
-<strong>Note:</strong> If you set the NACL_EXE_STDOUT, NACL_EXE_STDERR, or NACLLOG
-variables to redirect output to a file, you must run Chrome with the
-<code>--no-sandbox</code> flag.  You must also be careful that each variable points to
-a different file.
+<strong>Note:</strong> If you set the <code>NACL_EXE_STDOUT</code>, <code>NACL_EXE_STDERR</code>, or
+<code>NACLLOG</code> variables to redirect output to a file, you must run Chrome with
+the <code>--no-sandbox</code> flag.  You must also be careful that each variable points
+to a different file.
 </aside>
 <h4 id="redirecting-output-to-the-javascript-console">Redirecting output to the JavaScript console</h4>
 <p>You can also cause output from printf statements in your C/C++ code to be
@@ -122,17 +122,17 @@ relayed to the JavaScript side of your application through the Pepper messaging
 system, where you can then write the output to the JavaScript console. Follow
 these steps:</p>
 <ol class="arabic">
-<li><p class="first">Set the NACL_EXE_STDOUT and NACL_EXE_STDERR environment variables as
+<li><p class="first">Set the <code>NACL_EXE_STDOUT</code> and <code>NACL_EXE_STDERR</code> environment variables as
 follows:</p>
 <ul class="small-gap">
-<li><p class="first">NACL_EXE_STDOUT=DEBUG_ONLY:dev://postmessage</p>
+<li><p class="first"><code>NACL_EXE_STDOUT=DEBUG_ONLY:dev://postmessage</code></p>
 </li>
-<li><p class="first">NACL_EXE_STDERR=DEBUG_ONLY:dev://postmessage</p>
+<li><p class="first"><code>NACL_EXE_STDERR=DEBUG_ONLY:dev://postmessage</code></p>
 </li>
 </ul>
-<p>These settings tell Native Client to use PostMessage() to send output that
-your Native Client module writes to stdout and stderr to the JavaScript side
-of your application.</p>
+<p>These settings tell Native Client to use <code>PostMessage()</code> to send output
+that your Native Client module writes to stdout and stderr to the JavaScript
+side of your application.</p>
 </li>
 <li><p class="first">Register a JavaScript handler to receive messages from your Native Client
 module:</p>
@@ -162,7 +162,7 @@ JavaScript, your handler will need to be more complex.</p>
 <p>Once you&#8217;ve implemented a message handler and set up the environment
 variables as described above, you can check the JavaScript console to see
 output that your Native Client module prints to stdout and stderr. Keep in
-mind that your module makes a call to PostMessage() every time it flushes
+mind that your module makes a call to <code>PostMessage()</code> every time it flushes
 stdout or stderr.  Your application&#8217;s performance will degrade considerably
 if your module prints and flushes frequently, or if it makes frequent Pepper
 calls to begin with (e.g., to render).</p>
@@ -189,14 +189,14 @@ link it to the running code.</p>
 <h3 id="debugging-with-nacl-gdb"><span id="using-gdb"></span>Debugging with nacl-gdb</h3>
 <p>The Native Client SDK includes a command-line debugger that you can use to
 debug Native Client modules. The debugger is based on the GNU debugger <a class="reference external" href="http://www.gnu.org/software/gdb/">gdb</a>, and is located at
-<code>toolchain/&lt;platform&gt;_x86_newlib/bin/x86_64-nacl-gdb</code> (where <em>&lt;platform&gt;</em>
-is the platform of your development machine: <code>win</code>, <code>mac</code>, or
+<code>pepper_&lt;version&gt;/toolchain/&lt;platform&gt;_x86_newlib/bin/x86_64-nacl-gdb</code> (where
+<em>&lt;platform&gt;</em> is the platform of your development machine: <code>win</code>, <code>mac</code>, or
 <code>linux</code>).</p>
 <p>Note that this same copy of GDB can be used to debug any NaCl program,
 whether built using newlib or glibc for x86-32, x86-64 or ARM.  In the SDK,
 <code>i686-nacl-gdb</code> is an alias for <code>x86_64-nacl-gdb</code>, and the <code>newlib</code>
 and <code>glibc</code> toolchains both contain the same version of GDB.</p>
-<h4 id="debugging-pnacl-pexes-with-pepper-35"><span id="debugging-pnacl-pexes"></span>Debugging PNaCl pexes (with Pepper 35+)</h4>
+<h4 id="debugging-pnacl-pexes-pepper-35-or-later"><span id="debugging-pnacl-pexes"></span>Debugging PNaCl pexes (Pepper 35 or later)</h4>
 <p>If you want to use GDB to debug a program that is compiled with the PNaCl
 toolchain, you must have a copy of the pexe from <strong>before</strong> running
 <code>pnacl-finalize</code>. The <code>pnacl-finalize</code> tool converts LLVM bitcode
@@ -210,7 +210,7 @@ is not considered stable. This means that a debug copy of the PNaCl
 application created by a Pepper N SDK is only guaranteed to run
 with a matching Chrome version N. If the version of the debug bitcode pexe
 does not match that of Chrome then the translation process may fail, and
-you will see and error message in the JavaScript console.</p>
+you will see an error message in the JavaScript console.</p>
 <p>Also, make sure you are passing the <code>-g</code> <a class="reference internal" href="/native-client/devguide/devcycle/building.html#compile-flags"><em>compile option</em></a> to <code>pnacl-clang</code> to enable generating debugging info.
 You might also want to omit <code>-O2</code> from the compile-time and link-time
 options, otherwise GDB not might be able to print variables&#8217; values when
@@ -257,10 +257,12 @@ options.</li>
 <li><p class="first">Secondly, use <code>pnacl-translate</code> to convert your <code>pexe</code> to one or more
 <code>nexe</code> files.  For example:</p>
 <pre>
-&lt;NACL_SDK_ROOT&gt;/toolchain/win_pnacl/bin/pnacl-translate ^
-  --allow-llvm-bitcode-input hello_world.pexe -arch x86-32 -o hello_world_x86_32.nexe
-&lt;NACL_SDK_ROOT&gt;/toolchain/win_pnacl/bin/pnacl-translate ^
-  --allow-llvm-bitcode-input hello_world.pexe -arch x86-64 -o hello_world_x86_64.nexe
+nacl_sdk/pepper_&lt;version&gt;/toolchain/win_pnacl/bin/pnacl-translate \
+  --allow-llvm-bitcode-input hello_world.pexe -arch x86-32 \
+  -o hello_world_x86_32.nexe
+nacl_sdk/pepper_&lt;version&gt;/toolchain/win_pnacl/bin/pnacl-translate \
+  --allow-llvm-bitcode-input hello_world.pexe -arch x86-64 \
+  -o hello_world_x86_64.nexe
 </pre>
 <p>For this, use the non-finalized <code>pexe</code> file produced by
 <code>pnacl-clang</code>, not the <code>pexe</code> file produced by <code>pnacl-finalize</code>.
@@ -373,16 +375,16 @@ nacl-gdb and run the <code>continue</code> command.</p>
 <li><p class="first">Go to the directory with your source code, and run nacl-gdb from there. For
 example:</p>
 <pre class="prettyprint">
-cd &lt;NACL_SDK_ROOT&gt;/examples/hello_world_gles
-&lt;NACL_SDK_ROOT&gt;/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb
+cd nacl_sdk/pepper_&lt;version&gt;/examples/demo/drive
+nacl_sdk/pepper_&lt;version&gt;/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb
 </pre>
 <p>The debugger will start and show you a gdb prompt:</p>
 <pre class="prettyprint">
 (gdb)
 </pre>
 </li>
-<li><p class="first">For debugging PNaCl pexes run the following gdb command lines
-(skip to the next item if you are using NaCl instead of PNaCl):</p>
+<li><p class="first">Run the debugging command lines.</p>
+<p><strong>For PNaCl</strong>:</p>
 <pre class="prettyprint">
 (gdb) target remote localhost:4014
 (gdb) remote get nexe &lt;path-to-save-translated-nexe-with-debug-info&gt;
@@ -390,8 +392,7 @@ cd &lt;NACL_SDK_ROOT&gt;/examples/hello_world_gles
 (gdb) remote get irt &lt;path-to-save-NaCl-integrated-runtime&gt;
 (gdb) nacl-irt &lt;path-to-saved-NaCl-integrated-runtime&gt;
 </pre>
-</li>
-<li><p class="first">For NaCl nexes, run the following commands from the gdb command line:</p>
+<p><strong>For NaCl</strong>:</p>
 <pre class="prettyprint">
 (gdb) target remote localhost:4014
 (gdb) nacl-manifest &lt;path-to-your-.nmf-file&gt;
@@ -431,7 +432,7 @@ looks something like <code>C:/Users/&lt;username&gt;/AppData/Local/Google/Chrome
 SxS/Application/23.0.1247.1/nacl_irt_x86_64.nexe</code>.
 The <code>remote get irt &lt;path&gt;</code> saves that to the current working
 directory so that you do not need to find where exactly the IRT
-is stored alongside Chrome.</p>
+is stored.</p>
 </dd>
 <dt><code>nacl-irt &lt;path&gt;</code></dt>
 <dd><p class="first last">Tells the debugger where to find the Native Client Integrated Runtime
@@ -455,13 +456,13 @@ quotation marks around the path.</p>
 Windows:</p>
 <pre class="prettyprint">
 target remote localhost:4014
-nacl-manifest &quot;C:/&lt;NACL_SDK_ROOT&gt;/examples/hello_world_gles/newlib/Debug/hello_world_gles.nmf&quot;
+nacl-manifest &quot;C:/nacl_sdk/pepper_&lt;version&gt;/examples/hello_world_gles/newlib/Debug/hello_world_gles.nmf&quot;
 nacl-irt &quot;C:/Users/&lt;username&gt;/AppData/Local/Google/Chrome SxS/Application/23.0.1247.1/nacl_irt_x86_64.nexe&quot;
 </pre>
 <p>To save yourself some typing, you can put put these nacl-gdb commands in a
 script file, and execute the file when you run nacl-gdb, like so:</p>
 <pre class="prettyprint">
-&lt;NACL_SDK_ROOT&gt;/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb -x &lt;nacl-script-file&gt;
+nacl_sdk/pepper_&lt;version&gt;/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb -x &lt;nacl-script-file&gt;
 </pre>
 <p>If nacl-gdb connects successfully to Chrome, it displays a message such as
 the one below, followed by a gdb prompt:</p>
diff --git a/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html b/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html
index 7de0c6c..003a20d 100644
--- a/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html
+++ b/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html
@@ -106,13 +106,19 @@ file and several libraries, which are on the order of 1.5MB).</li>
 due to licensing considerations), we recommend that you use the glibc
 library.</strong></p>
 <aside class="note">
-<p><strong>Notes:</strong></p>
+<p><strong>Disclaimer:</strong></p>
 <ul class="small-gap">
 <li><strong>None of the above constitutes legal advice, or a description of the legal
 obligations you need to fulfill in order to be compliant with the LGPL or
 newlib licenses. The above description is only a technical explanation of
 the differences between newlib and glibc, and the choice you must make
 between the two libraries.</strong></li>
+</ul>
+
+</aside>
+<aside class="note">
+<p><strong>Notes:</strong></p>
+<ul class="small-gap">
 <li>Static linking with glibc is rarely used. Use this feature with caution.</li>
 <li>The standard C++ runtime in Native Client is provided by libstdc++; this
 library is independent from and layered on top of glibc. Because of
diff --git a/native_client_sdk/src/doc/devguide/coding/3D-graphics.rst b/native_client_sdk/src/doc/devguide/coding/3D-graphics.rst
index 44c08c0..6bd800b 100644
--- a/native_client_sdk/src/doc/devguide/coding/3D-graphics.rst
+++ b/native_client_sdk/src/doc/devguide/coding/3D-graphics.rst
@@ -507,13 +507,13 @@ Don'ts
   ``GL_ARRAY_BUFFER`` and ``GL_ELEMENT_ARRAY_BUFFER``, but that would be
   expensive overhead and it is not recommended.
 
-* **Don't call ``glGet*`` or ``glCheck*`` during rendering.** This is normal
+* **Don't call glGet* or glCheck* during rendering.** This is normal
   advice for OpenGL programs, but is particularly important for 3D on
   Chrome. Calls to any OpenGL ES 2.0 function whose name begins with these
   strings blocks the Native Client thread. This includes ``glGetError``; avoid
   calling it in release builds.
 
-* **Don't use fixed point (``GL_FIXED``) vertex attributes.** Fixed point
+* **Don't use fixed point (GL_FIXED) vertex attributes.** Fixed point
   attributes are not supported in OpenGL ES 2.0, so emulating them in OpenGL ES
   2.0 is slow. By default, ``GL_FIXED`` support is turned off in the Pepper 3D
   API.
@@ -525,6 +525,6 @@ Don'ts
   ``glSubBufferData`` for example) the entire buffer must be reprocessed. To
   avoid this problem, keep static and dynamic data in different buffers.
 
-* **Don't call ``glDisable(GL_TEXTURE_2D)``.** This is an OpenGL ES 2.0
+* **Don't call glDisable(GL_TEXTURE_2D).** This is an OpenGL ES 2.0
   error. Each time it is called, an error messages will appear in Chrome's
   ``about:gpu`` tab.
diff --git a/native_client_sdk/src/doc/devguide/coding/native-client-modules.rst b/native_client_sdk/src/doc/devguide/coding/native-client-modules.rst
index ed2030d..b892fd2 100644
--- a/native_client_sdk/src/doc/devguide/coding/native-client-modules.rst
+++ b/native_client_sdk/src/doc/devguide/coding/native-client-modules.rst
@@ -140,9 +140,9 @@ the NaCl SDK), these three components are specified in the file
 .. naclcode::
 
   namespace pp {
-  Module* CreateModule() {
-    return new HelloTutorialModule();
-  }
+    Module* CreateModule() {
+      return new HelloTutorialModule();
+    }
   }
 
 The ``CreateModule()`` factory function is the main binding point between a
diff --git a/native_client_sdk/src/doc/devguide/coding/progress-events.rst b/native_client_sdk/src/doc/devguide/coding/progress-events.rst
index 3e0a404..3275821 100644
--- a/native_client_sdk/src/doc/devguide/coding/progress-events.rst
+++ b/native_client_sdk/src/doc/devguide/coding/progress-events.rst
@@ -22,8 +22,8 @@ chapter assumes you are familiar with the material presented in the
   :class: note
 
   The load_progress example illustrates progress event handling. You can find
-  this code in the ``/examples/tutorial/load_progress/`` directory in the Native
-  Client SDK download.
+  this code in the ``/pepper_<version>/examples/tutorial/load_progress/`` 
+  directory in the Native Client SDK download.
 
 Module loading and progress events
 ==================================
diff --git a/native_client_sdk/src/doc/devguide/coding/view-focus-input-events.rst b/native_client_sdk/src/doc/devguide/coding/view-focus-input-events.rst
index 859304f..8714bde 100644
--- a/native_client_sdk/src/doc/devguide/coding/view-focus-input-events.rst
+++ b/native_client_sdk/src/doc/devguide/coding/view-focus-input-events.rst
@@ -20,12 +20,12 @@ programming techniques. The ``input_events`` example is used to
 illustrate how your module can react to keyboard and mouse input
 event.  The ``mouse_lock`` example is used to illustrate how your module
 can react to view change events. You can find these examples in the
-``/examples/api/input_events`` and ``/examples/api/mouse_lock``
-directories in the Native Client SDK.  There is also the
-ppapi_simple library that can be used to to implement most of the
-boiler plate.  The ``pi_generator`` example in
-``/examples/demo/pi_generator`` uses ppapi_simple to manage view
-change events and 2D graphics.
+``/pepper_<version>/examples/api/input_event`` and 
+``/pepper_<version>/examples/api/mouse_lock`` directories in the Native Client
+SDK.  There is also the ppapi_simple library that can be used to to implement
+most of the boiler plate.  The ``pi_generator`` example in
+``/pepper_<version>/examples/demo/pi_generator`` uses ppapi_simple to manage
+view change events and 2D graphics.
 
 
 Overview
diff --git a/native_client_sdk/src/doc/devguide/devcycle/debugging.rst b/native_client_sdk/src/doc/devguide/devcycle/debugging.rst
index 14cba30..326ac22 100644
--- a/native_client_sdk/src/doc/devguide/devcycle/debugging.rst
+++ b/native_client_sdk/src/doc/devguide/devcycle/debugging.rst
@@ -27,15 +27,15 @@ application:
    memory information are visible. If they are not, right click in the header
    row and select the memory items from the popup menu that appears.
 
-A browser window running a Native Client application will have at least two
-processes associated with it: a process for the app's top level (the render
-process managing the page including its HTML and any JavaScript) and one or
-more processes for each instance of a Native Client module embedded in the page
-(each process running native code from one nexe file). The top-level process
-appears with the application's icon and begins with the text "App:". A Native
-Client process appears with a Chrome extension icon (a jigsaw puzzle piece
-|puzzle|) and begins with the text "Native Client module" followed by the URL
-of its manifest file.
+A browser window running a Native Client application has at least two processes
+associated with it: a process for the app's top level (the render process
+managing the page including its HTML and JavaScript) and one or more
+processes for each instance of a Native Client module embedded in the page
+(each process running native code from one nexe or pexe file). The top-level
+process appears with the application's icon and begins with the text "Tab:". 
+A Native Client process appears with a Chrome extension icon (a jigsaw puzzle
+piece |puzzle|) and begins with the text "Native Client module:" followed by the
+URL of its manifest file.
 
 From the Task Manager you can view the changing memory allocations of all the
 processes associated with a Native Client application. Each process has its own
@@ -52,9 +52,10 @@ increase the amount of Native Client's diagnostic output by setting the
 following `environment variables
 <http://en.wikipedia.org/wiki/Environment_variable>`_:
 
-* NACL_PLUGIN_DEBUG=1
-* NACL_SRPC_DEBUG=[1-255] (use a higher number for more verbose debug output)
-* NACLVERBOSITY=[1-255]
+* ``NACL_PLUGIN_DEBUG=1``
+* ``NACL_SRPC_DEBUG=[1-255]`` (use a higher number for more verbose debug
+  output)
+* ``NACLVERBOSITY=[1-255]``
 
 Basic debugging
 ===============
@@ -62,12 +63,12 @@ Basic debugging
 Writing messages to the JavaScript console
 ------------------------------------------
 
-You can send messages from your C/C++ code to JavaScript using the PostMessage
-call in the :doc:`Pepper messaging system <../coding/message-system>`. When the
-JavaScript code receives a message, its message event handler can call
-`console.log() <https://developer.mozilla.org/en/DOM/console.log>`_ to write
-the message to the JavaScript `console </devtools/docs/console-api>`_ in
-Chrome's Developer Tools.
+You can send messages from your C/C++ code to JavaScript using the 
+``PostMessage()`` call in the :doc:`Pepper messaging system 
+<../coding/message-system>`. When the JavaScript code receives a message, its 
+message event handler can call `console.log() 
+<https://developer.mozilla.org/en/DOM/console.log>`_ to write the message to the
+JavaScript `console </devtools/docs/console-api>`_ in Chrome's Developer Tools.
 
 Debugging with printf
 ---------------------
@@ -88,10 +89,12 @@ calling fprintf() directly, or by using cover functions like these:
 By default stdout and stderr will appear in Chrome's stdout and stderr stream
 but they can also be redirected as described below.
 
+
 Redirecting output to log files
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You can redirect stdout and stderr to output files by setting these environment variables:
+You can redirect stdout and stderr to output files by setting these environment
+variables:
 
 * ``NACL_EXE_STDOUT=c:\nacl_stdout.log``
 * ``NACL_EXE_STDERR=c:\nacl_stderr.log``
@@ -106,10 +109,10 @@ variable as follows:
 .. Note::
   :class: note
 
-  **Note:** If you set the NACL_EXE_STDOUT, NACL_EXE_STDERR, or NACLLOG
-  variables to redirect output to a file, you must run Chrome with the
-  ``--no-sandbox`` flag.  You must also be careful that each variable points to
-  a different file.
+  **Note:** If you set the ``NACL_EXE_STDOUT``, ``NACL_EXE_STDERR``, or
+  ``NACLLOG`` variables to redirect output to a file, you must run Chrome with
+  the ``--no-sandbox`` flag.  You must also be careful that each variable points
+  to a different file.
 
 Redirecting output to the JavaScript console
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -119,15 +122,15 @@ relayed to the JavaScript side of your application through the Pepper messaging
 system, where you can then write the output to the JavaScript console. Follow
 these steps:
 
-#. Set the NACL_EXE_STDOUT and NACL_EXE_STDERR environment variables as
+#. Set the ``NACL_EXE_STDOUT`` and ``NACL_EXE_STDERR`` environment variables as
    follows:
 
-   * NACL_EXE_STDOUT=DEBUG_ONLY:dev://postmessage
-   * NACL_EXE_STDERR=DEBUG_ONLY:dev://postmessage
+   * ``NACL_EXE_STDOUT=DEBUG_ONLY:dev://postmessage``
+   * ``NACL_EXE_STDERR=DEBUG_ONLY:dev://postmessage``
 
-   These settings tell Native Client to use PostMessage() to send output that
-   your Native Client module writes to stdout and stderr to the JavaScript side
-   of your application.
+   These settings tell Native Client to use ``PostMessage()`` to send output
+   that your Native Client module writes to stdout and stderr to the JavaScript
+   side of your application.
 
 #. Register a JavaScript handler to receive messages from your Native Client
    module:
@@ -161,7 +164,7 @@ these steps:
    Once you've implemented a message handler and set up the environment
    variables as described above, you can check the JavaScript console to see
    output that your Native Client module prints to stdout and stderr. Keep in
-   mind that your module makes a call to PostMessage() every time it flushes
+   mind that your module makes a call to ``PostMessage()`` every time it flushes
    stdout or stderr.  Your application's performance will degrade considerably
    if your module prints and flushes frequently, or if it makes frequent Pepper
    calls to begin with (e.g., to render).
@@ -201,8 +204,8 @@ Debugging with nacl-gdb
 The Native Client SDK includes a command-line debugger that you can use to
 debug Native Client modules. The debugger is based on the GNU debugger `gdb
 <http://www.gnu.org/software/gdb/>`_, and is located at
-``toolchain/<platform>_x86_newlib/bin/x86_64-nacl-gdb`` (where *<platform>*
-is the platform of your development machine: ``win``, ``mac``, or
+``pepper_<version>/toolchain/<platform>_x86_newlib/bin/x86_64-nacl-gdb`` (where
+*<platform>* is the platform of your development machine: ``win``, ``mac``, or
 ``linux``).
 
 Note that this same copy of GDB can be used to debug any NaCl program,
@@ -212,8 +215,8 @@ and ``glibc`` toolchains both contain the same version of GDB.
 
 .. _debugging_pnacl_pexes:
 
-Debugging PNaCl pexes (with Pepper 35+)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Debugging PNaCl pexes (Pepper 35 or later)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you want to use GDB to debug a program that is compiled with the PNaCl
 toolchain, you must have a copy of the pexe from **before** running
@@ -229,7 +232,7 @@ is not considered stable. This means that a debug copy of the PNaCl
 application created by a Pepper N SDK is only guaranteed to run
 with a matching Chrome version N. If the version of the debug bitcode pexe
 does not match that of Chrome then the translation process may fail, and
-you will see and error message in the JavaScript console.
+you will see an error message in the JavaScript console.
 
 Also, make sure you are passing the ``-g`` :ref:`compile option
 <compile_flags>` to ``pnacl-clang`` to enable generating debugging info.
@@ -293,10 +296,12 @@ pepper 35 or later.)
   .. naclcode::
     :prettyprint: 0
 
-    <NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-translate ^
-      --allow-llvm-bitcode-input hello_world.pexe -arch x86-32 -o hello_world_x86_32.nexe
-    <NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-translate ^
-      --allow-llvm-bitcode-input hello_world.pexe -arch x86-64 -o hello_world_x86_64.nexe
+    nacl_sdk/pepper_<version>/toolchain/win_pnacl/bin/pnacl-translate \
+      --allow-llvm-bitcode-input hello_world.pexe -arch x86-32 \
+      -o hello_world_x86_32.nexe
+    nacl_sdk/pepper_<version>/toolchain/win_pnacl/bin/pnacl-translate \
+      --allow-llvm-bitcode-input hello_world.pexe -arch x86-64 \
+      -o hello_world_x86_64.nexe
 
   For this, use the non-finalized ``pexe`` file produced by
   ``pnacl-clang``, not the ``pexe`` file produced by ``pnacl-finalize``.
@@ -419,24 +424,25 @@ Follow the instructions below to debug your module with nacl-gdb:
 #. Go to the directory with your source code, and run nacl-gdb from there. For
    example::
 
-     cd <NACL_SDK_ROOT>/examples/hello_world_gles
-     <NACL_SDK_ROOT>/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb
+     cd nacl_sdk/pepper_<version>/examples/demo/drive
+     nacl_sdk/pepper_<version>/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb
 
    The debugger will start and show you a gdb prompt::
 
      (gdb)
 
-#. For debugging PNaCl pexes run the following gdb command lines
-   (skip to the next item if you are using NaCl instead of PNaCl)::
+#. Run the debugging command lines.
 
+   **For PNaCl**::
+   
      (gdb) target remote localhost:4014
      (gdb) remote get nexe <path-to-save-translated-nexe-with-debug-info>
      (gdb) file <path-to-save-translated-nexe-with-debug-info>
      (gdb) remote get irt <path-to-save-NaCl-integrated-runtime>
      (gdb) nacl-irt <path-to-saved-NaCl-integrated-runtime>
 
-#. For NaCl nexes, run the following commands from the gdb command line::
-
+   **For NaCl**::
+   
      (gdb) target remote localhost:4014
      (gdb) nacl-manifest <path-to-your-.nmf-file>
      (gdb) remote get irt <path-to-save-NaCl-integrated-runtime>
@@ -474,7 +480,7 @@ Follow the instructions below to debug your module with nacl-gdb:
      SxS/Application/23.0.1247.1/nacl_irt_x86_64.nexe``.
      The ``remote get irt <path>`` saves that to the current working
      directory so that you do not need to find where exactly the IRT
-     is stored alongside Chrome.
+     is stored.
 
    ``nacl-irt <path>``
      Tells the debugger where to find the Native Client Integrated Runtime
@@ -495,13 +501,13 @@ Follow the instructions below to debug your module with nacl-gdb:
    Windows::
 
      target remote localhost:4014
-     nacl-manifest "C:/<NACL_SDK_ROOT>/examples/hello_world_gles/newlib/Debug/hello_world_gles.nmf"
+     nacl-manifest "C:/nacl_sdk/pepper_<version>/examples/hello_world_gles/newlib/Debug/hello_world_gles.nmf"
      nacl-irt "C:/Users/<username>/AppData/Local/Google/Chrome SxS/Application/23.0.1247.1/nacl_irt_x86_64.nexe"
 
    To save yourself some typing, you can put put these nacl-gdb commands in a
    script file, and execute the file when you run nacl-gdb, like so::
 
-     <NACL_SDK_ROOT>/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb -x <nacl-script-file>
+     nacl_sdk/pepper_<version>/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb -x <nacl-script-file>
 
    If nacl-gdb connects successfully to Chrome, it displays a message such as
    the one below, followed by a gdb prompt::
diff --git a/native_client_sdk/src/doc/devguide/devcycle/dynamic-loading.rst b/native_client_sdk/src/doc/devguide/devcycle/dynamic-loading.rst
index 3b8dbee..d0242f0 100644
--- a/native_client_sdk/src/doc/devguide/devcycle/dynamic-loading.rst
+++ b/native_client_sdk/src/doc/devguide/devcycle/dynamic-loading.rst
@@ -84,7 +84,7 @@ library.**
 .. Note::
   :class: note
 
-  **Notes:**
+  **Disclaimer:**
 
   * **None of the above constitutes legal advice, or a description of the legal
     obligations you need to fulfill in order to be compliant with the LGPL or
@@ -92,6 +92,13 @@ library.**
     the differences between newlib and glibc, and the choice you must make
     between the two libraries.**
 
+
+
+.. Note::
+  :class: note
+
+  **Notes:**
+
   * Static linking with glibc is rarely used. Use this feature with caution.
 
   * The standard C++ runtime in Native Client is provided by libstdc++; this