NOTE: THIS DOCUMENT IS OUT OF DATE.

Summary

Prerequisites

1. You need a debug version of your nexe.  If you're working with adapted SDK makefiles you should be able to generate that pretty easily.
2. You need the debug version of your nexe on the server you want Chrome to connect to *and* on a Linux machine that you can use to run gdb as the debug client. Alternatively, you can use a Linux machine as the web server and the debug client. While you can run Chrome to show the page with the nexe on any OS, gdb has to be run on Linux. Using gdb under Cygwin will not work.
3. Unless you are running both Chrome and gdb on the same machine, you'll need a tool for port forwarding.  A proxy can be built with the SDK for windows, or you can use ssh which should work on all platforms.
4. You need a copy of Chrome M14 or later.
5. You need a debug client (for Linux you can use gdb)

Blocking Issue

Instructions

1. Start a server to host your nexes (you can use the one provided in the SDK).
2. For debugging to work you must use the *_dbg.nexe (that is, a nexe with debug symbols intact). Don't forget to update the HTML file to point to a manifest (typically *_dbg.nmf) that points to the debug nexes.
3. In a command prompt, the following sequence will launch chrome with a debug_stub enabled:
   
   C:\location\of\chrome.exe --enable-nacl-debug --no-sandbox
   
   
4. When you point Chrome at your server and run your nexe, you will notice that the nexe appears to hang on load.  You can run netstat -a | grep 4014 and verify that chrome has opened a port on the loopback interface:
   
   TCP    127.0.0.1:4014         UNAME0-W:0            LISTENING
   
   
5. You can now use ssh or the SDK's rsp_proxy to forward that port to an external interface: 0.0.0.0:4014. On Windows something like this will do, if you have PuTTY installed and plink.exe in your path:
   
   plink your.linux.host -R 4014:localhost:4014
   
   
6. You can now connect to the nexe in Chrome from the Linux box, using gdb:
   
   > gdb
   ...
   Hey, I'm GDB 7.x.  Check me out!  http://wiki/Main/Gdb7x
   (gdb) target remote YOUR.WIN.MACHINE.IP:4014
   Remote debugging using YOUR.WIN.MACHINE.IP:40140x0000000c00020080
    in ?? ()
   
   
7. In gdb, connect to the debug target:
   
   (gdb) target remote localhost:4014
   
   
8. Load symbols from the nexe, using the address in %r15 + 0x20080 (this is typically 0xc00020080):
   
   (gdb) add-symbol-file /path/to/YOUR_NEXE_x86_64_dbg.nexe 0xc00020080
   
   This enables symbolic debugging.  Now you can set breakpoints, you can step, you can continue and disassemble, get information on register state, etc...
   
   
9. Sometimes (rarely) the offset is not 0xc00020080. To find out what the offset is, run
   
   nacl-objdump -xf /path/tp/YOUR_NEXE_x86_64_dbg.nexe
   
   and look for the address in the VMA column for the .text segment, e.g.,:
   
   Sections:
   Idx Name          Size      VMA               LMA               File off  Algn
     0 .init         00000080  0000000000020000  0000000000020000  00010000  2**5
                     CONTENTS, ALLOC, LOAD, READONLY, CODE
     1 .text         00057900  0000000000020080  0000000000020080  00010080  2**5
                     CONTENTS, ALLOC, LOAD, READONLY, CODE
   
   You should use 0xc00000000 plus the VMA for .text as the offset when you load the symbols in gdb.