Add debugging information for nacl_io library.

native_client_sdk/src/doc/devguide/devcycle/debugging.rst

 .. _devcycle-debugging:
 
 #########
 Debugging
 #########
 
 This document describes tools and techniques you can use to debug, monitor,
 and measure your application's performance.
 
 .. contents:: Table Of Contents
@@ skipping 71 matching lines @@
   void logmsg(const char* pMsg){
     fprintf(stdout,"logmsg: %s\n",pMsg);
   }
   void errormsg(const char* pMsg){
     fprintf(stderr,"logerr: %s\n",pMsg);
   }
 
 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:
 
 Redirecting output to log files
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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``
 
@@ skipping 404 matching lines @@
   quit gdb
 
 See the `gdb documentation
 <http://sourceware.org/gdb/current/onlinedocs/gdb/#toc_Top>`_ for a
 comprehensive list of gdb commands. Note that you can abbreviate most commands
 to just their first letter (``b`` for break, ``c`` for continue, and so on).
 
 To interrupt execution of your module, press <Ctrl-c>. When you're done
 debugging, close the Chrome window and type ``q`` to quit gdb.
 
-Debugging with other tools
-==========================
+Non-Standard Debugging
+======================
+
+.. _nacl-io-debugging:
+
+nacl_io
+-------
+
+The logging system for the :doc:`nacl_io library <../coding/nacl_io>` writes
+directly to the ``stderr`` stream of the NaCl process. It deliberately bypasses
+the standard library functions implemented in nacl_io to avoid circular calls to
+itself.

[Sam Clegg, 2014/09/30 17:17:02]

I would put this paragraph in the NaCl document rather than the debugging
document.  Its basically saying that while nacl_io redirects things like
printf() the redirection doesn't apply to its own internal logging.  The
internal logging appears as normal stderr as described in this page already.  

So basically what this paragraph says is that nacl_io logging does go to the
standard place, but most other I/O under nacl_io does not.  Sorry if thats not a
very clear statement :(

[Sam Clegg, 2014/09/30 17:28:37]

Sorry, I meant to write "the nacl_io documentation".

[jpmedley, 2014/10/01 21:17:11]

Done.

+
+The stderr from the process is by default visible in the terminal that launched
+chrome (at least on mac and linux). Be sure that when you launch chrome it
+doesn't attach to an existing instance. One simple way to do this is to pass a
+new directory to chrome as your user data directory (``chrome
+--user-data-dir=<newdir>``). It's also possible to redirect the NaCl's stderr to
+other places such as, for example, :ref:`log files  
+<redirecting-output-to-log>`. 

[Sam Clegg, 2014/09/30 17:17:02]

This second paragraph is just about how to capture stderr of chrome and is not
related to nacl_io in particular.  If you want to keep the detail about
--user-data-dir you could add it above to the paragraph that reads: "By default
stdout and stderr will appear in Chrome's stdout and stderr stream..."

[jpmedley, 2014/10/01 21:17:11]

Done.

+
+Alternative Debuggers
+---------------------
 
 If you cannot use the :ref:`Visual Studio add-in <visual_studio>`, or you want
 to use a debugger other than nacl-gdb, you must manually build your module as a
 Pepper plugin (sometimes referred to as a "`trusted
 <http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics#TOC-Trusted-vs-Untrusted>`_"
 or "in-process" plugin).  Pepper plugins (.DLL files on Windows; .so files on
 Linux; .bundle files on Mac) are loaded directly in either the Chrome renderer
 process or a separate plugin process, rather than in Native Client. Building a
 module as a trusted Pepper plugin allows you to use standard debuggers and
 development tools on your system, but when you're finished developing the
 plugin, you need to port it to Native Client (i.e., build the module with one
 of the toolchains in the NaCl SDK so that the module runs in Native Client).
 For details on this advanced development technique, see `Debugging a Trusted
 Plugin
 <http://www.chromium.org/nativeclient/how-tos/debugging-documentation/debugging-a-trusted-plugin>`_.
 Note that starting with the ``pepper_22`` bundle, the NaCl SDK for Windows
 includes pre-built libraries and library source code, making it much easier to
 build a module into a .DLL.
 
 
 .. |menu-icon| image:: /images/menu-icon.png
 .. |puzzle| image:: /images/puzzle.png