GPU workaround to simulate Out of Memory errors with large textures

[chromium-blink-merge.git] / native_client_sdk / doc_generated / sdk / examples.html

{{+bindTo:partials.standard_nacl_article}}

<span class="target" id="sdk-examples-2"></span><section id="examples">
<h1 id="examples">Examples</h1>
<p>Every Native Client SDK bundle comes with a folder of example applications.
Each example demonstrates one or two key Native Client programming concepts.
After you&#8217;ve <a class="reference internal" href="/native-client/sdk/download.html"><em>downloaded the SDK</em></a>, follow the instructions
on this page to build and run the examples.</p>
<p>Your version of Chrome must be equal to or greater than the version of your SDK
bundle. For example, if you&#8217;re developing with the <code>pepper_35</code> bundle, you
must use Google Chrome version 35 or greater. To find out what version of Chrome
you&#8217;re using, type <code>about:chrome</code> or <code>about:version</code> in the Chrome address
bar.</p>
<h2 id="build-the-sdk-examples"><span id="id1"></span>Build the SDK examples</h2>
<p>The Makefile scripts for the SDK examples can build multiple versions of the
examples using any of the three SDK toolchains (newlib, glibc, and PNaCl) and in
both release and debug configurations. Note that some examples, <code>dlopen</code> for
example, build only with particular toolchains.</p>
<p>Find the toolchains for each example by looking at the <code>VALID_TOOLCHAINS</code>
variable in the Makefile for a particular example. The first item listed is the
default. It&#8217;s built when you run an example make file without parameters. for
example running make in the <code>core</code> directory of pepper_35 builds the example
using the <code>newlib</code> toolchain.</p>
<pre class="prettyprint">
$ cd pepper_35/examples/api/core
$ make
  CXX  newlib/Release/core_x86_32.o
  LINK newlib/Release/core_unstripped_x86_32.nexe
  VALIDATE newlib/Release/core_unstripped_x86_32.nexe
  CXX  newlib/Release/core_x86_64.o
  LINK newlib/Release/core_unstripped_x86_64.nexe
  VALIDATE newlib/Release/core_unstripped_x86_64.nexe
  CXX  newlib/Release/core_arm.o
  LINK newlib/Release/core_unstripped_arm.nexe
  VALIDATE newlib/Release/core_unstripped_arm.nexe
  STRIP newlib/Release/core_x86_32.nexe
  STRIP newlib/Release/core_x86_64.nexe
  STRIP newlib/Release/core_arm.nexe
  CREATE_NMF newlib/Release/core.nmf
</pre>
<p>As you can see, this produces a number of architecture specific nexe files in
the <code>pepper_35/examples/api/core/Release</code> directory.  Create debug versions by
using the <code>CONFIG</code> parameter of the make command.</p>
<pre class="prettyprint">
$make CONFIG=Debug
</pre>
<p>This creates similar output, but in <code>pepper_35/examples/api/core/Debug</code>.</p>
<p>Select a different toolchain with the <code>TOOLCHAIN</code> parameter.  For example:</p>
<pre class="prettyprint">
$ cd pepper_35/examples/api/core
$ make TOOLCHAIN=pnacl CONFIG=Release
  CXX  pnacl/Release/core.o
  LINK pnacl/Release/core_unstripped.bc
  FINALIZE pnacl/Release/core_unstripped.pexe
  CREATE_NMF pnacl/Release/core.nmf
</pre>
<p>You can also set <code>TOOLCHAIN</code> to <code>all</code> to build all Release versions with
default toolchains.</p>
<pre class="prettyprint">
$ cd pepper_35/examples/api/core
$ make TOOLCHAIN=all
make TOOLCHAIN=newlib
make[1]: Entering directory 'pepper_35/examples/api/core'
  CXX  newlib/Release/core_x86_32.o
  LINK newlib/Release/core_unstripped_x86_32.nexe
  VALIDATE newlib/Release/core_unstripped_x86_32.nexe
  CXX  newlib/Release/core_x86_64.o
  LINK newlib/Release/core_unstripped_x86_64.nexe
  VALIDATE newlib/Release/core_unstripped_x86_64.nexe
  CXX  newlib/Release/core_arm.o
  LINK newlib/Release/core_unstripped_arm.nexe
  VALIDATE newlib/Release/core_unstripped_arm.nexe
  STRIP newlib/Release/core_x86_32.nexe
  STRIP newlib/Release/core_x86_64.nexe
  STRIP newlib/Release/core_arm.nexe
  CREATE_NMF newlib/Release/core.nmf
make[1]: Leaving directory 'pepper_35/examples/api/core'
make TOOLCHAIN=glibc
make[1]: Entering directory 'pepper_35/examples/api/core'
  CXX  glibc/Release/core_x86_32.o
  LINK glibc/Release/core_unstripped_x86_32.nexe
  VALIDATE glibc/Release/core_unstripped_x86_32.nexe
  CXX  glibc/Release/core_x86_64.o
  LINK glibc/Release/core_unstripped_x86_64.nexe
  VALIDATE glibc/Release/core_unstripped_x86_64.nexe
  ...
  (content excerpted)
  ...
</pre>
<h3 id="build-results"><span id="id2"></span>Build results</h3>
<p>After running <code>make</code>, example directories will contain one or more of the
following subdirectories, depending on which Makefile you run:</p>
<ul class="small-gap">
<li><code>newlib</code> with subdirectories <code>Debug</code> and <code>Release</code>;</li>
<li><code>glibc</code> with subdirectories <code>Debug</code> and <code>Release</code>;</li>
<li><code>pnacl</code> with subdirectories <code>Debug</code> and <code>Release</code>;</li>
</ul>
<p>For the newlib and glibc toolchains the Debug and Release subdirectories
contain .nexe files for all target architectures. For the PNaCl toolchain
they contain a single .pexe file. PNaCl debug also produces pre-translated
.nexe files, for ease of debugging. All Debug and Release directories contain
a manifest (.nmf) file that references the associated .nexe or .pexe files.
For information about Native Client manifest files, see the <a class="reference internal" href="/native-client/overview.html"><em>Technical
Overview</em></a>.</p>
<p>For details on how to use <code>make</code>, see the <a class="reference external" href="http://www.gnu.org/software/make/manual/make.html">GNU &#8216;make&#8217; Manual</a>. For details on how to
use the SDK toolchain itself, see <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building Native Client Modules</em></a>.</p>
<h2 id="run-the-sdk-examples"><span id="running-the-sdk-examples"></span>Run the SDK examples</h2>
<h3 id="disable-the-chrome-cache"><span id="disable-chrome-cache"></span>Disable the Chrome cache</h3>
<p>Chrome&#8217;s intelligent caching caches resources aggressively. When building a
Native Client application you should disable the cache to make sure that Chrome
loads the latest version. Intelligent caching only remains inactive while
Developer Tools are open. Otherwise, agressive caching continues.</p>
<ol class="arabic simple">
<li>Open Chrome&#8217;s developer tools by clicking the menu icon <img alt="menu-icon" src="/native-client/images/menu-icon.png" /> and
choosing Tools &gt; Developer tools.</li>
<li>Click the gear icon <img alt="gear-icon" src="/native-client/images/gear-icon.png" /> in the bottom right corner of the Chrome
window.</li>
<li>Under the &#8220;General&#8221; settings, check the box next to &#8220;Disable cache&#8221;.</li>
</ol>
<h3 id="run-the-examples"><span id="id3"></span>Run the examples</h3>
<p>To run the SDK examples, use the <code>make run</code> command:</p>
<pre class="prettyprint">
$ cd pepper_35/examples/api/core
$ make run
</pre>
<p>This launches a local HTTP server that serves the example. It then launches
Chrome with the address of this server, usually <code>http://localhost:5103</code>.
After you close Chrome, the local HTTP server automatically shuts down.</p>
<p>This command tries to find an executable named <code>google-chrome</code> in your
<code>PATH</code> environment variable. If it can&#8217;t, you&#8217;ll get an error message like
this:</p>
<pre class="prettyprint">
pepper_35/tools/common.mk:415: No valid Chrome found at CHROME_PATH=
pepper_35/tools/common.mk:415: *** Set CHROME_PATH via an environment variable, or command-line..  Stop.
</pre>
<h3 id="add-an-environment-variable-for-chrome"><span id="add-an-env-variable-for-chrome"></span>Add an environment variable for Chrome</h3>
<p>Set the CHROME_PATH environment variable to the location of your Chrome
executable.</p>
<ul class="small-gap">
<li><p class="first">On Windows:</p>
<p>The default install location of Chrome is
<code>C:\Program Files (x86)\Google\Chrome\Application\chrome.exe</code> for Chrome
stable and
<code>C:\Users\&lt;username&gt;\AppData\Local\Google\Chrome SxS\Application\chrome.exe</code>
for Chrome Canary. Try looking in those directories first:</p>
<pre class="prettyprint">
&gt; set CHROME_PATH=&lt;Path to chrome.exe&gt;
</pre>
</li>
<li><p class="first">On Linux:</p>
<pre class="prettyprint">
$ export CHROME_PATH=&lt;Path to google-chrome&gt;
</pre>
</li>
<li><p class="first">On Mac:</p>
<p>The default install location of Chrome is
<code>/Applications/Google Chrome.app/Contents/MacOS/Google Chrome</code> for
Chrome Stable and
<code>Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary</code>
for Chrome Canary. Note that you have to reference the executable inside the
application bundle, not the top-level <code>.app</code> directory:</p>
<pre class="prettyprint">
$ export CHROME_PATH=&lt;Path to Google Chrome&gt;
</pre>
</li>
</ul>
<h2 id="run-the-sdk-examples-as-chrome-apps"><span id="run-sdk-examples-as-packaged"></span>Run the SDK examples as Chrome apps</h2>
<p>Each example can also be launched as a Chrome apps. A Chrome app is a special
zip file (with a .crx extension) hosted in the Chrome Web Store. This file
contains all of the application parts: A Chrome Web Store manifest file
(<code>manifest.json</code>), an icon, and all of the regular Native Client application
files. Refer to <a class="reference external" href="/apps">What are Chrome Apps</a> for more information about
creating a Chrome app.</p>
<p>Some Pepper features, such as <a class="reference external" href="pepper_stable/cpp/classpp_1_1_t_c_p_socket">TCP</a> or <a class="reference external" href="pepper_stable/cpp/classpp_1_1_u_d_p_socket">UDP</a> socket access, are only allowed
in <a class="reference external" href="/apps">Chrome apps</a>. The examples that use these features must be run as
<a class="reference external" href="/apps">Chrome apps</a>, by using the following command:</p>
<pre class="prettyprint">
$ make run_package
</pre>
<p>You can use <code>TOOLCHAIN</code> and <code>CONFIG</code> parameters as described above to run
with a different toolchain or configuration.</p>
<h2 id="debugging-the-sdk-examples"><span id="id5"></span>Debugging the SDK examples</h2>
<p>The NaCl SDK uses <a class="reference external" href="https://www.gnu.org/software/gdb/">GDB</a> to debug Native
Client code. The SDK includes a prebuilt version of GDB that is compatible with
NaCl code. To use it, run the <code>make debug</code> command from an example directory:</p>
<pre class="prettyprint">
$ make debug
</pre>
<p>This launches Chrome with the <code>--enable-nacl-debug</code> flag set. This flag causes
Chrome to pause when a NaCl module is first loaded, waiting for a connection
from gdb. The <code>make debug</code> command also simultaneously launches GDB and loads
the symbols for that NEXE. To connect GDB to Chrome, in the GDB console, type:</p>
<pre class="prettyprint">
(gdb) target remote :4014
</pre>
<p>This tells GDB to connect to a TCP port on <code>localhost:4014</code>, the port that
Chrome is listening on. GDB will respond:</p>
<pre class="prettyprint">
Remote debugging using :4014
0x000000000fa00080 in ?? ()
</pre>
<p>At this point, you can use the standard GDB commands to debug your NaCl module.
The most common commands you will use to debug are <code>continue</code>, <code>step</code>,
<code>next</code>, <code>break</code> and <code>backtrace</code>. See
<a class="reference internal" href="/native-client/devguide/devcycle/debugging.html"><em>Debugging</em></a> for more information about
debugging a Native Client application.</p>
</section>

{{/partials.standard_nacl_article}}