This page describes strategies you can use to debug your modules, concentrating on techniques that don't use a debugger. Although a debugger exists for Linux (as of the April 23 release), no Native Client debugger is available for Mac or Windows.
Note: We're actively working on improving the debuggability of Native Client modules. If you'd like to help — by porting a debugger to Mac or Windows, for example — please volunteer! You can contact us on the Native Client Discuss group.
If your module can run both as a standalone Linux or Mac application and within Native Client, then you can use a debugger such as GDB, KDbg, or Xcode to debug the standalone form of your application.
Note: Building standalone applications is not supported on Windows.
For examples of creating a module that also works standalone,
see the earth
, life
, tone
,
and voronoi
examples under native_client/tests
.
It's easier to fix bugs you find at compile time
than those you find at runtime.
When you compile your module,
use gcc
flags such as
-Werror
and -Wall
to help ensure that your code is as clean as possible.
For example:
nacl-g++ earth.cc -Wall -Werror -O3 -mfpmath=sse -msse -fomit-frame-pointer -lpthread -lm -o earth_release.nexe
If a bug doesn't appear in the standalone app version of a module,
you might have to use
printf
and assert
to debug your module when it runs in Native Client.
Note:
Using printf
can be useful on Linux and Mac,
but it's more difficult on Windows.
For the latest Windows testing tips, see the wiki page
DebuggingModulesOnWindows.
Some notes on using
printf
and assert
:
printf
from only one thread.
assert
does not generate core dumps.
printf
and assert
output,
you might see debugging output from other processes —
the plug-in and sel_ldr
.
Here's an example of using printf
:
#include <stdio.h> ... printf("Multimedia system failed to initialize! errno: %d\n", errno);
Here's an example of using assert
:
#include <assert.h> int foo(int x) { assert(x != 0); ... }
On Linux and Mac, if you launch your browser from the command line,
the output of printf
and assert
goes
to the window you used to enter the command.
Make sure the window has a large scroll buffer,
so you don't lose output.
Better yet, use the GNU Screen program
or an Emacs shell,
so you can easily search the output.
Platform How to launch Firefox from the command line Linux /usr/bin/firefox2
Mac /Applications/Firefox.app/Contents/MacOS/firefox-bin
If you launch the browser using a menu, button, or icon
(rather than from the
command line)
the output of printf
or assert
goes to a
location that depends on the platform you're using.
Platform Default output location Linux $HOME/.xsession-errors
Mac /var/log/system.log
The Linux nacl-gdb
tool is
a version of GDB that can deal with Native Client's
memory and address space conventions.
For details,
see the
nacl-gdb
page.
Mac and Windows don't have Native Client ports of GDB or any other debuggers. Debuggers need to be ported to Native Client because Native Client modules' use of segmented memory protection confuses the kernel exception handler, which in turn interferes with handling breakpoints. Also, the segmented structure of the Native Client address space interferes with symbol resolution.
Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license.