The 32bit Native Client GDB can be only built on Linux in a NaCl source checkout:
When debugging NaCl programs nacl-gdb works pretty much like you're use to. There are two modes in nacl-gdb. A NaCl program can either be in service runtime (see Glossary) code or in native client code. The prompt shows which mode the program is in, "(sr-gdb)" or "(nc-gdb)".
Remember, apropos is your friend. If you can't remember the name of a command, type apropos <word> and hopefully you'll see the command you are looking for in the output. For nacl commands, try apropos nacl.
Assuming you have downloaded the SDK. Though downloading or building the modified GNU toolchain should be enough. You will also need to fetch and build Native Client Sources to run this example. Note: the hello_world example from the SDK examples is not suitable for command-line debugging. Although you can attach to the browser process to debug it, for this simple demonstration we take a more trivial hello_world module that only outputs data to stdout.
Examining core files of Native Client programs has not been well tested yet.
Hardware watchpoints in native-client mode currently do not work. They should work in service-runtime mode.
Access to thread local variables in native-client mode does not currently work.
They should work in service-runtime mode.
During the transition between service-runtime and native-client modes GDB can get confused about what the current mode is. The symptom is memory accesses give errors. If one is stepi-ing, just continue to stepi a few more instructions until the transition is complete.
When stopped in one mode, "info breakpoints" won't print symbolic addresses of breakpoints in the other mode.
There's a FIXME in the code regarding restoring longjmp breakpoints. So assume stepping over a longjmp may not work.
From GDB's point of view, when running a Native Client program there are actually two programs: sel_ldr and the Native Client program itself. The Native Client program runs in its own protected space, and assumes that all of its symbols won't collide with sel_ldr (the Service Runtime). Therefore GDB needs to keep the symbols of each separate. It does this by becoming modal. At any particular point in a thread's execution, it is either in the Service Runtime side of things or it is in the Native Client side of things. GDB tracks this state (lazily to not affect performance).
To assist the user in knowing what state the program is currently in, and thus for example what set of symbols are accessible, nacl-gdb includes the current state in the prompt. When a thread is stopped in Native Client mode the prompt is (nc-gdb). When a thread is stopped in Service Runtime mdoe the prompt is (sr-gdb). As one switches among threads GDB updates its record of what state the thread is in, and updates the prompt accordingly.
Use the --loader option to specify a different path for sel_ldr. Example:
nacl apply-runtime command [args ...]
Temporarily switch to service-runtime mode and then run command there.
This is useful if you are sitting at a (nc-gdb) prompt and want to run a command "as if" you are sitting at a (sr-gdb) prompt. Examples are examining service-runtime state or setting a breakpoint in sel_ldr.
nacl apply command [args ...]
Temporarily switch to native-client mode and then run command there.
This is useful if you are sitting at a (sr-gdb) prompt and want to run a command "as if" you are sitting at a (nc-gdb) prompt. Examples are examining the state of the native-client program or setting a breakpoint there.
set nacl service-runtime-args [args ...]
Set the arguments to sel_ldr, NOT including the NaCl program or its arguments. Use this to specify arguments for sel_ldr itself, e.g., -h d:D. Do not specify the -f argument, gdb supplies that itself.
NOTE: This option is only useful when debugging NaCl programs, i.e., when the "main" executable is a .nexe program. In other words, you started your debugging session with something like: