Initial contribution of the Adaptation Documentation.
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License
"Eclipse Public License v1.0" which accompanies this distribution,
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
Nokia Corporation - initial contribution.
Contributors:
-->
<!DOCTYPE concept
PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A" xml:lang="en"><title>Keyword reference (A-C)</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>This page lists the keywords starting from A to C. </p>
<section id="GUID-51EA4180-A0FC-5DCE-8CEA-C43EA24330E4"><title>##</title> <codeblock id="GUID-A7F1E72D-6C4D-55A2-8AC3-54793C208B16" xml:space="preserve">##</codeblock> <p> <i>BUILDROM only</i> </p> <p>Performs textual substitution.
All subsequent instances of the two characters ## are replaced with
an empty string. </p> <p>Note that there is no UNDEFINE facility and
substitutions are applied in an unspecified order. </p> </section>
<section id="GUID-56A2AC12-CA1A-531C-94DB-E493735D70C8"><title>ABI_DOWNGRADE</title> <codeblock id="GUID-8C1D1941-8B89-581B-A10D-04EC11A72A3E" xml:space="preserve">ABI_DOWNGRADE from->to</codeblock> <p> <i>BUILDROM only</i> </p> <p>Allows <codeph>BUILDROM</codeph> to substitute a compatible executable if a specified source file
is not available. </p> <p>The use of this keyword is not appropriate
for production devices, but is useful in the development environment
as it increases the chances of producing a ROM in the presence of
build problems. </p> <p>For example, </p> <codeblock id="GUID-C72215D5-AADE-56EF-A04D-5B0AF7D66244" xml:space="preserve">ABI_DOWNGRADE THUMB->ARMI</codeblock> <p>This substitutes \ARMI\ for \THUMB\ if a specified source file
cannot be found. </p> <p>Another example is in localisation support.
Problem suppression allows <codeph>BUILDROM</codeph> to handle a missing <filepath>source.Enn</filepath> file by specifying <filepath>source.EXT</filepath> instead. In a final pass, if any file is still not available after
applying these downgrades, then <codeph>BUILDROM</codeph> will simply
comment out the line in the <filepath>.oby</filepath> file in the
hope that the missing file is not vital to the ROM. If this behaviour
is not appropriate, then the command line option <codeph>-s</codeph> can be used to enforce stricter behaviour and cause <codeph>BUILDROM</codeph> to terminate after the final pass if files are missing. </p> </section>
<section id="GUID-7CE887E7-C2C3-5F87-AB40-AFA571A68A23"><title>alias[[HWVD]]</title> <codeblock id="GUID-87077748-C01D-542D-8DD1-D22CDA0EEB07" xml:space="preserve">alias[[HWVD]] = <existing-file> <destination-file> [ directory-attribute-list ]</codeblock> <p> <i>rombuild and rofsbuild</i> </p> <p>Creates an additional
filesystem entry, which refers to an existing file. <codeph>rombuild</codeph> allows directory aliases to preserve the guarantee that the ROM
filesystem should not contain cycles. The existing-file must not be
hidden, and both names are now available to resolve DLL static linkage. </p> </section>
<section id="GUID-F5A15F4D-2CD5-530D-8031-51546EE28E1C"><title>align</title> <codeblock id="GUID-7B53F30F-B034-545F-AA0F-D7D42567FDE6" xml:space="preserve">align = <hex-number></codeblock> <p> <i>rombuild only</i> </p> <p>Specifies the alignment boundary
for the file that follows immediately after the <codeph>align</codeph> statement. </p> </section>
<section id="GUID-50B4683F-C796-577A-8444-D75465BC9563"><title>area</title> <codeblock id="GUID-2D0D97FA-353E-5910-B9C8-78C1D70E1E1C" xml:space="preserve">area = <name></codeblock> <p> <i>rombuild only</i> </p> <p>Defines the area in which the
executable will be relocated. The specified name must have been previously
defined in the <xref href="GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A.dita#GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A/GUID-0FA9D55F-4081-5A46-ABD7-C95406827730">area</xref> control statement. </p> </section>
<section id="GUID-0FA9D55F-4081-5A46-ABD7-C95406827730"><title>area</title> <codeblock id="GUID-B8BCB889-06B1-53D3-907C-85A1BED9B59F" xml:space="preserve">area = <name> <run-address> <maxlength></codeblock> <p> <i>rombuild only</i> </p> <p>Defines a new relocation area.
The area is identified by the specified name. Executable files placed
in this area will be relocated so that they run in the address range <codeph>X</codeph>, where <codeph>X</codeph> is defined as: </p> <p> <codeph><run-address></codeph> <= <codeph>X</codeph> < <codeph><run-address></codeph> + <codeph><maxlength></codeph>. </p> <p>The Bootstrap is required
to copy the relevant subset of ROM to the run address at Boot time.
The main purpose of this is to relocate time-critical executables
to internal or tightly-coupled RAM. </p> </section>
<section id="GUID-A97C37B0-8909-58FA-9BC2-2BD68F25A8B0"><title>ascii</title> <codeblock id="GUID-86D82203-CD9C-53F9-8D19-10731894D9C8" xml:space="preserve">ascii</codeblock> <p> <i>rombuild only</i> </p> <p>Indicates that this is not a Unicode
build. </p> </section>
<section id="GUID-19D49CB3-C180-5F32-9488-63C71A3D5991"><title>attrib</title> <codeblock id="GUID-7A831599-A874-5EC7-864A-063E0A0FD04A" xml:space="preserve">attrib = [ s | S ][ h | H ][ r | R | w | W ] | hide</codeblock> <p> <i>rombuild and rofsbuild</i> </p> <p>Files may have the System,
Hidden, read-only and writable attributes. </p> <p>File attributes
are copied from the source file and are then overridden by the attributes
specified by this keyword. Specifying <codeph>S</codeph>, <codeph>H</codeph>, or <codeph>R</codeph> sets the corresponding attribute;
specifying <codeph>s</codeph>, <codeph>h</codeph> or <codeph>r</codeph> clears it. </p> <p> <codeph>W</codeph> and <codeph>w</codeph> are
synonyms for <codeph>R</codeph> and r respectively. To mark a file
in the ROM as being writable, specify <codeph>attrib=W</codeph>. </p> <p>As this is a ROM, the file cannot be physically modified even
if the read-only attribute is cleared, but it is useful to mark files
as writeable so that copies are made writeable, for example on a CF
card or a RAM file system. </p> <p>Using the <codeph>hide</codeph> attribute indicates that the file should be included in the ROM
but not recorded in the ROM filesystem. If the file is a DLL it will
be available for resolving static links from other files in the same
ROM, but not available to RAM-loaded software or DLLs in an extension
ROM. </p> </section>
<section id="GUID-34A37221-7BCF-5C6C-AC15-BD9C2E9B0465"><title>AUTO-BITMAP</title> <codeblock id="GUID-986754B7-966A-5987-8DEA-D3DA3B957450" xml:space="preserve">AUTO-BITMAP=<source> <dest></codeblock> <p> <i>BUILDROM only</i> </p> <p>Either selects a compressed MBM
file if generating an XIP ROM image, or the original source file if
generating a non-XIP ROM image </p> <p>This statement translates to <xref href="GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A.dita#GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A/GUID-F68BF5AB-9C25-5736-9EF6-496548D08C74">COMPRESSED-BITMAP</xref> for XIP ROMs and to <xref href="GUID-A27BD4D8-8B0E-57C8-9C15-736109297DEA.dita#GUID-A27BD4D8-8B0E-57C8-9C15-736109297DEA/GUID-23851F44-7FAC-5B99-8D15-44099A61A4E4">data</xref> for non-XIP ROMs. </p> </section>
<section id="GUID-BEB026CF-0136-545D-9348-78A8C559EBB1"><title>autosize</title> <codeblock id="GUID-38F40AFF-9C04-5CA6-B33C-2703FEFBD1D3" xml:space="preserve">autosize = <block size></codeblock> <p> <i>rofsbuild only</i> </p> <p>Reduces the size to a whole number
of blocks where <block size> defines the granularity. </p> <p>For
example if <xref href="GUID-43852F38-4841-5E6F-927B-A38ED4424F0C.dita#GUID-43852F38-4841-5E6F-927B-A38ED4424F0C/GUID-208C0FE4-DFC0-55C3-B6D7-F18C74F1A699">rofsize</xref> is set to 0x30000 and the actual image size is 0x1234,
then the generated image size <i>without</i> the autosize option is
0x30000. If autosize is set to 0x1000, then the generated image size
is 0x2000. </p> </section>
<section id="GUID-3ECB9A8C-7F90-5556-936A-ACFB5A3630C5"><title>BINARY_SELECTION_ORDER</title> <codeblock id="GUID-51ACF277-7DDF-51E5-8951-958E86B36BFF" xml:space="preserve">BINARY_SELECTION_ORDER=<source-build1>,<source-build2>,..</codeblock> <p>This causes the tools to check the given locations for files
in the specified order: </p> <codeblock id="GUID-82BC7A3E-7B6D-59C0-8D23-9CB94D8D76D0" xml:space="preserve">BINARY_SELECTION_ORDER=GCCE, ARMV5_ABIv2</codeblock> <p>causes <codeph>buildrom</codeph> to first check the GCCE directory
for files and then if not found there, to look in the <codeph>ARMV5_ABIv2</codeph> directory. </p> </section>
<section id="GUID-9CF1F2B0-A9F2-5463-8308-787A91F74742"><title>BITMAP</title> <codeblock id="GUID-B06CF354-3CD4-58F8-B1D8-F9BA2D013929" xml:space="preserve">BITMAP=<source> <dest></codeblock> <p> <i>BUILDROM only</i> </p> <p>Generates an <i>uncompressed</i> Symbian platform XIP ROM format MBM file from the <source> MBM
file and copies it into the ROM at <dest>. </p> </section>
<section id="GUID-A24CE761-5675-575A-A85C-74D16A7A17FC"><title>bootbinary</title> <codeblock id="GUID-DBEC685B-EC83-5E67-81E9-60DD87BCDC2E" xml:space="preserve">bootbinary = <boot-file-name></codeblock> <p> <i>rombuild only</i> </p> <p>The file name of the ROM's bootstrap
code, which on ARM CPUs appears at physical address 0x00000000 when
the machine is booted. </p> </section>
<section id="GUID-8964BB60-D323-56F3-9093-DA623CA56500"><title>BTrace</title> <codeblock id="GUID-6D3AD725-2F25-59AD-BCF4-0C2AA7EF8388" xml:space="preserve">BTrace = N1 [N2 [N3 [N4 [N5 [N6 [N7 [N8]]]]]]]</codeblock> <p> <i>rombuild only</i> </p> <p>A keyword for configuring the
behaviour of the Symbian platform mechanism for generating and capturing
trace information (<xref href="GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441.dita"><apiname>BTrace</apiname></xref>). </p> <p>Each trace
has a category which is an 8-bit value. The kernel implements a filter
that enables traces in each category to be either discarded (disabled)
or passed to the trace handler (enabled). This keyword sets the initial
state of that filter, i.e. to indicate whether a trace category is
enabled or disabled. </p> <p>A trace category is one of the <xref href="GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441.dita#GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441/GUID-E26B390F-390C-372B-B60F-9F788119A98B"><apiname>BTrace::TCategory</apiname></xref> enum values. </p> <p>The BTrace keyword
takes up to eight 32-bit integers, representing a set of 256 bits.
Each bit in the set is associated with a single category: If a bit
is set it means that the corresponding category is enabled - if a
bit is not set it means that the corresponding category is disabled. </p> <p>The rule for mapping the bits in these eight integers to the <xref href="GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441.dita#GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441/GUID-E26B390F-390C-372B-B60F-9F788119A98B"><apiname>BTrace::TCategory</apiname></xref> values is as follows: to turn on trace
category <codeph>C</codeph>, where <codeph>C</codeph> is one of the <xref href="GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441.dita#GUID-5BF17780-AD31-30CF-AFD9-915CBDA74441/GUID-E26B390F-390C-372B-B60F-9F788119A98B"><apiname>BTrace::TCategory</apiname></xref> enum values, set bit position <codeph>C%32</codeph> to one in integer <codeph>Nx where x = C/32</codeph>. </p> <fig id="GUID-A1108376-F661-5105-B87E-26274FA497EC">
<image href="GUID-EE7086B4-A60A-55B2-85DC-28F07F9E227E_d0e55772_href.png" placement="inline"/>
</fig> <p>For example to turn on the trace category <xref href="GUID-103470F8-577A-37B4-80A2-A0CD61B9FF7D.dita"><apiname>ECodeSegs</apiname></xref>, (i.e. the trace generated when code segments are created and destroyed
mapped into out of processes, and when memory is committed and decommitted)
you would specify: </p> <codeblock id="GUID-F4B5636C-5E7F-5EF1-8C3C-3FA723593C4C" xml:space="preserve">BTrace 0x00000200</codeblock> <p>which turns on bit position 9 (counting from zero and starting
at the right hand side of the integer). Note that there is no need
to specify the remaining 7 integers if they all have zero values,
as zero is assumed by default. </p> <p>See also <xref href="..\..\guide\Base-subsystem-guide\d\Base_How_to_BTrace.html" scope="external">Base How To BTrace</xref>. </p> </section>
<section id="GUID-95B716E3-EC86-5B3A-9784-2930AC6B1E8B"><title>BTraceBuffer</title> <codeblock id="GUID-CE1E4478-FC49-55B0-97E6-73C5FFFCF49A" xml:space="preserve">BTraceBuffer = N</codeblock> <p> <i>rombuild only</i> </p> <p>A keyword for configuring the
behaviour of the Symbian platform trace handler. </p> <p>Use this
keyword to set the initial size for any memory buffer used to store
trace data. </p> <p>See also <xref href="..\..\guide\Base-subsystem-guide\d\Base_How_to_BTrace.html" scope="external">Base How To BTrace</xref>. </p> </section>
<section id="GUID-3D917AF7-F4FF-54F4-8CDB-5647B440137D"><title>BTraceMode</title> <codeblock id="GUID-E28E7DEB-83B7-59B5-87DB-8008A2037E7A" xml:space="preserve">BTraceMode = N</codeblock> <p> <i>rombuild only</i> </p> <p>A keyword for configuring the
behaviour of the Symbian platform trace handler. </p> <p>Use this
keyword to set the initial mode of the trace handler. This BTRaceBuffer
keyword takes a single integer that specifies the mode. For the default
trace handler supplied with Symbian platform, this will be one of
the <codeph>RBTrace::TMode</codeph> enum values defined in the header
file <filepath>d32btrace.h</filepath>. </p> <p>See also <xref href="..\..\guide\Base-subsystem-guide\d\Base_How_to_BTrace.html" scope="external">Base How To BTrace</xref>. </p> </section>
<section id="GUID-03F5D906-B29F-4375-9EA4-BDEEFE53645F"><title>capability</title><codeblock xml:space="preserve">capability = <capability-names></codeblock><p><i>rombuild
only</i></p><p>This keyword overrides platform security capabilities
of the executable specified in the OBY file. For information on the
use of capabilities and current capability set, see <xref href="GUID-EA20E614-C911-4EE9-92B5-C8F9B657D59E.dita">Platform security
architecture</xref> in the <xref href="GUID-2FC268F3-5EC2-40DB-B3EA-0E2D5C6EFCAD.dita">Symbian C++ Developer
Library</xref>.</p></section>
<section id="GUID-4DE045B8-CD31-43DF-8136-63FB9FB65003"><title>clustersize</title><codeblock xml:space="preserve">clustersize=<cluster-size></codeblock><p>This keyword
specifies the cluster size for a FAT image generated by the ROM tools.
The keyword must be specified in the <codeph>DATA_IMAGE[x]</codeph> section of the OBY file. If it is not specified in the <codeph>DATA_IMAGE[x]</codeph> section, a warning is displayed. </p><p>The value of the cluster
size must meet the following conditions:</p><p><ul>
<li><p>The cluster size must be between 512 bytes and 32KB (sector
size).</p><ul>
<li><p>For a FAT16 image, the cluster size must be in the range 4101–
65508 bytes.</p></li>
<li><p>For a FAT32 image, the cluster size must be greater than 65541
bytes.</p></li>
</ul></li>
<li><p>The cluster size must belong to the geometric progression series,
512, 1024, 2048, 4096, and so on. A geometric progression series is
a sequence of numbers where each term after the first is found by
multiplying the previous one by a fixed number called common ratio.
In this series, the first number of the series is 512 and the common
ratio is 2.</p></li>
</ul></p></section>
<section id="GUID-255FE5A6-B1F7-59E3-AB5A-65F990F96103"><title>code-align</title> <codeblock id="GUID-0D61CEC0-4E3F-5ABF-AA63-CD7FFAA03B55" xml:space="preserve">code-align = <hex-number></codeblock> <p> <i>rombuild only</i> </p> <p>This keyword specifies the alignment
for the executable's code. It indicates the start address of a code
segment that must be aligned to a specified value. If the original
address of the code segment does not match the alignment, the whole
executable file is relocated to meet alignment. After the image is
loaded in RAM a block of memory is unused. </p> <p>The code alignment
is an optimisation depending on the hardware the ROM is being built
for. Setting the code align can allow the ROM to be built in such
a way that it reduces the work for the CPU when loading the code that
is, it can be loaded in one pass. This improves the performance. If
it is unaligned it can take multiple passes. </p> <p>For example: </p> <ul>
<li id="GUID-BE0872C9-330C-5812-9D89-6051B8848616"><p>Define an <filepath>.oby</filepath> file: </p> <codeblock id="GUID-D2CD9719-3B20-556B-9805-622172B73D3C" xml:space="preserve">file=\epoc32\release\armv5\urel\helloworld.exe sys\bin\helloworld.exe code-align = 0x1000</codeblock> </li>
<li id="GUID-60585DD9-6935-5291-A8DC-F4822C668750"><p>Build ROM with
the above <filepath>.oby</filepath> file. </p> </li>
<li id="GUID-49388D88-A033-5A3C-9915-E09A92C8B682"><p>The log file
is: </p> <codeblock id="GUID-37EBFA91-4977-5C5B-A336-CF4046A9AAAB" xml:space="preserve">Code Align to 8161f000. Skipped 2296 bytes
********************************************************************
Processing file \epoc32\release\armv5\urel\helloworld.exe
Load Address: 8161ef88
Size: 000004a8
Uids: 1000007a e8000047 00000000 0dcafc2f
Entry point: 8161f000
Code start addr: 8161f000</codeblock> </li>
</ul> <p>In the log file, we can find that the code start address
of <filepath>helloworld.exe</filepath> matches the alignment <codeph>0x1000</codeph>. To do that, a gap is generated before <filepath>helloworld.exe</filepath> that is,after the image is loaded in RAM
a block of memory is unused. </p> <p>It is unique for <filepath>ekern.exe</filepath>, which is at least page aligned. If the value of <codeph>code-align</codeph> is less than page size, <filepath>ekern.exe</filepath> will be aligned
as page size. Otherwise, <filepath>ekern.exe</filepath> will be aligned
as the value of <codeph>code-align</codeph>. </p> <p> <b>Note:</b> If an <filepath>.oby</filepath> file includes this keyword, the
size of ROM image is same. But the size loaded in RAM is slightly
larger than the original. </p> </section>
<section id="GUID-70AAC0A2-5865-5378-998B-199B5FA60C50"><title>coffwrapper</title> <codeblock id="GUID-038904AC-E274-5D55-8A1D-B18C8722F6A1" xml:space="preserve">coffwrapper</codeblock> <p> <i>rombuild only</i> </p> <p>Indicates that a COFF ROM wrapper
is required. </p> </section>
<section id="GUID-C4BD2116-A9A2-5EB6-8795-AD7AB3230640"><title>collapse</title> <codeblock id="GUID-9DB36B1E-85AA-5C4E-821E-92AEC021E928" xml:space="preserve">collapse = <cpu> <compiler> <mode></codeblock> <p> <i>rombuild only</i> </p> <p>This is only supported when the
<cpu> is ARM and the <compiler> is GCC. </p> <p>The <mode>
can take one of the following values: </p> <table id="GUID-68DF266C-4A53-53AE-8D08-A8FED4B90330">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<tbody>
<row>
<entry><p>1</p> </entry>
<entry><p>collapse import thunks only </p> </entry>
</row>
<row>
<entry><p>2</p> </entry>
<entry><p>collapse import thunks and vtables </p> </entry>
</row>
<row>
<entry><p>3</p> </entry>
<entry><p>collapse branches </p> </entry>
</row>
</tbody>
</tgroup>
</table> </section>
<section id="GUID-FDED610B-0483-54F8-9129-123047536445"><title>compress</title> <codeblock id="GUID-9EB3C403-9AE7-588A-8C0D-0803D81F8CC0" xml:space="preserve">compress</codeblock> <p> <i>rombuild only</i> </p> <p>Compresses the resulting ROM image
using the Deflate, Huffman+LZ77 algorithm. </p> </section>
<section id="GUID-F68BF5AB-9C25-5736-9EF6-496548D08C74"><title>COMPRESSED-BITMAP</title> <codeblock id="GUID-6F0FF54A-1F93-584B-B0FF-150BC4DE32F2" xml:space="preserve">COMPRESSED-BITMAP=<source> <dest></codeblock> <p> <i>BUILDROM only</i> </p> <p>Generates a <i>compressed</i> Symbian
platform XIP ROM format MBM file from the <source> MBM file and
copies it into the ROM at <dest>. </p> </section>
<section id="GUID-2322ABCF-3771-5965-8FBE-6AE58240ED2D"><title>coreimage</title> <codeblock id="GUID-EA3E1E01-05E1-5265-A461-1C8B3825409A" xml:space="preserve">coreimage = <core image file></codeblock> <p> <i>rofsbuild only</i> </p> <p>This tells rofsbuild that the
generation of the core image is not required and that the specified
core image should be used to as the base for generating the extension
image. </p> </section>
<section id="GUID-20A2663B-FE05-5E0A-ACF9-669EDDC8317C"><title>codepagingoverride</title> <codeblock id="GUID-294656EC-7B3F-56AE-B2AB-51C6C0155CE9" xml:space="preserve">codepagingoverride [NOPAGING | ALWAYSPAGE | DEFAULTUNPAGED | DEFAULTPAGED]</codeblock> <p> <i>rombuild and rofsbuild </i> </p> <p>This keyword sets the
page attributes of executables at a global level. It is applicable
to all executables in ROM or ROFS partitions. It takes a single argument,
which can be one of the following: </p> <table id="GUID-BB8AD876-102A-5A66-AAA5-886CE2FAE68B">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<thead>
<row>
<entry>Argument</entry>
<entry>Purpose</entry>
</row>
</thead>
<tbody>
<row>
<entry><p> <i>NOPAGING</i> </p> </entry>
<entry><p>All executables are marked as unpaged, irrespective of whether
they are marked as paged or unpaged in the <filepath>MMP</filepath> file. </p> </entry>
</row>
<row>
<entry><p> <i>ALWAYSPAGE</i> </p> </entry>
<entry><p>All executables are marked as paged, irrespective of whether
they are marked as paged or unpaged in the <filepath>MMP</filepath> file. </p> </entry>
</row>
<row>
<entry><p> <i>DEFAULTUNPAGED</i> </p> </entry>
<entry><p>All executables that are not marked as paged or unpaged
are marked as unpaged by default. </p> </entry>
</row>
<row>
<entry><p> <i>DEFAULTPAGED</i> </p> </entry>
<entry><p>All executables that are not marked as paged or unpaged
are marked as paged by default. </p> </entry>
</row>
</tbody>
</tgroup>
</table> <p>For example, the following entry in the Obey file marks
all the executables as unpaged: </p> <codeblock id="GUID-1E03583B-EEF5-59AC-B7AF-6C56D7239781" xml:space="preserve">codepagingoverride NOPAGING</codeblock> </section>
<section id="GUID-9F070479-77D7-57E0-B142-64B3A23BBB1F"><title>codepagingpolicy</title> <codeblock id="GUID-E31A0AA2-9839-5D41-BC01-CCAB9719E086" xml:space="preserve">codepagingpolicy [NOPAGING | ALWAYSPAGE | DEFAULTUNPAGED | DEFAULTPAGED]</codeblock> <p> <i>rombuild and rofsbuild </i> </p> <p>This sets a flag in
the ROM when it is built, and the loader in the kernel decides a policy
for executables that are in default state (neither marked as paged
nor as unpaged). This keyword takes a single argument, which can be
one of the possible values listed in <xref href="GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A.dita#GUID-B9698943-0D4E-5B18-B7E4-448A0E21876A/GUID-20A2663B-FE05-5E0A-ACF9-669EDDC8317C">codepagingoverride</xref>. The default value for codepagingpolicy
is <codeph>DEFAULTPAGED</codeph>. </p> <p>For example, the following
entry in the Obey file instructs the loader not to page the executables
in default state: </p> <codeblock id="GUID-E1F72061-2E1F-5045-BABC-174DEC56B011" xml:space="preserve">codepagingpolicy NOPAGING</codeblock> </section>
</conbody></concept>