This page describes
For debugging 32-bit Native Client modules, refer to the corresponding documentation.
git clone http://git.chromium.org/native_client/nacl-gdb.git
Configure and build as the native debugger:
Now you have
The debugger works by debugging the Service Runtime (see Glossary) together with the NaCl program. Thinking of the debugging techniques, simply treat NaCl program as yet another shared library loaded by the service runtime.
ATTENTION: service runtime and NaCl program will likely have equally named symbols, for example,
First you need to specify service runtime binary. Do it as usually:
Specify full command line for the service runtime: service runtime command-line arguments, NaCl binary and NaCl command line arguments (if applicable). With
Unfortunately for certain service runtime there is no way to deduce NaCl program name from the service runtime command line. For example,
For now, you always have to specify the NaCl binary explicitly, with this new
Here is another example, for debugging NaCl dynamically linked executable. Here
All of the above may be quite annoying. Make good use of
WORK IN PROGRESS. These notes are incomplete. Follow-up questions on debugging are welcome on email@example.com.
Getting satisfactory results from nacl64-gdb requires binaries with symbolic information for your NaCl module. As with any debugging situation, NaCl modules should be built with -g and not stripped. If you want symbolic information for the browser as well you can find release builds of Chromium with symbolic information at http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html. Typical workflow:
The workflow is helpful for situations where a crash happens relatively early, for example during initialization, and you would like to capture the crash in the debugger. You can forgo the part about suspending Chrome when hunting for bugs that happen in response to a user action.
Another common debug scenario is an infinite loop. Keep in mind that sometimes a profiler can be a useful tool for finding such problems. See the Native Client developer pages on profiling.
If the symbol is non-ambiguous, set the breakpoints as usually:
If setting breakpoint on NaCl symbol before NaCl program is loaded, gdb will ask if the breakpoint should be pending on future shared library load. Recall that NaCl program is treated as yet another shared library and answer 'y':
If the symbol is ambiguous, breakpoint will be set on a symbol found by symbol lookup, which depends on the current context. And this might be not stable, and breakpoints may migrate when re-set, for example, at program restart. To avoid this, try to specify not only the symbol name, but the source file as well:
Here is an example for debugging dynamically linked executable:
The major known issue is that