<p>In addition to these extensions, the <code><nobr>COMMON</nobr></code>directive in <code><nobr>obj</nobr></code> also supportsdefault-<code><nobr>WRT</nobr></code> specification like<code><nobr>EXTERN</nobr></code> does (explained in<a href="#section-6.2.7">section 6.2.7</a>). So you can also declare thingslike<p><pre>common  foo     10:wrt dgroup common  bar     16:far 2:wrt data common  baz     24:wrt data:6</pre><h3><a name="section-6.3">6.3 <code><nobr>win32</nobr></code>: Microsoft Win32 Object Files</a></h3><p>The <code><nobr>win32</nobr></code> output format generates MicrosoftWin32 object files, suitable for passing to Microsoft linkers such asVisual C++. Note that Borland Win32 compilers do not use this format, butuse <code><nobr>obj</nobr></code> instead (see<a href="#section-6.2">section 6.2</a>).<p><code><nobr>win32</nobr></code> provides a default output file-nameextension of <code><nobr>.obj</nobr></code>.<p>Note that although Microsoft say that Win32 object files follow the<code><nobr>COFF</nobr></code> (Common Object File Format) standard, theobject files produced by Microsoft Win32 compilers are not compatible withCOFF linkers such as DJGPP's, and vice versa. This is due to a differenceof opinion over the precise semantics of PC-relative relocations. Toproduce COFF files suitable for DJGPP, use NASM's<code><nobr>coff</nobr></code> output format; conversely, the<code><nobr>coff</nobr></code> format does not produce object files thatWin32 linkers can generate correct output from.<h4><a name="section-6.3.1">6.3.1 <code><nobr>win32</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a></h4><p>Like the <code><nobr>obj</nobr></code> format,<code><nobr>win32</nobr></code> allows you to specify additionalinformation on the <code><nobr>SECTION</nobr></code> directive line, tocontrol the type and properties of sections you declare. Section types andproperties are generated automatically by NASM for the standard sectionnames <code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and<code><nobr>.bss</nobr></code>, but may still be overridden by thesequalifiers.<p>The available qualifiers are:<ul><li><code><nobr>code</nobr></code>, or equivalently<code><nobr>text</nobr></code>, defines the section to be a code section.This marks the section as readable and executable, but not writable, andalso indicates to the linker that the type of the section is code.<li><code><nobr>data</nobr></code> and <code><nobr>bss</nobr></code> definethe section to be a data section, analogously to<code><nobr>code</nobr></code>. Data sections are marked as readable andwritable, but not executable. <code><nobr>data</nobr></code> declares aninitialised data section, whereas <code><nobr>bss</nobr></code> declares anuninitialised data section.<li><code><nobr>rdata</nobr></code> declares an initialised data sectionthat is readable but not writable. Microsoft compilers use this section toplace constants in it.<li><code><nobr>info</nobr></code> defines the section to be aninformational section, which is not included in the executable file by thelinker, but may (for example) pass information <em>to</em> the linker. Forexample, declaring an <code><nobr>info</nobr></code>-type section called<code><nobr>.drectve</nobr></code> causes the linker to interpret thecontents of the section as command-line options.<li><code><nobr>align=</nobr></code>, used with a trailing number as in<code><nobr>obj</nobr></code>, gives the alignment requirements of thesection. The maximum you may specify is 64: the Win32 object file formatcontains no means to request a greater section alignment than this. Ifalignment is not explicitly specified, the defaults are 16-byte alignmentfor code sections, 8-byte alignment for rdata sections and 4-byte alignmentfor data (and BSS) sections. Informational sections get a default alignmentof 1 byte (no alignment), though the value does not matter.</ul><p>The defaults assumed by NASM if you do not specify the above qualifiersare:<p><pre>section .text    code  align=16 section .data    data  align=4 section .rdata   rdata align=8 section .bss     bss   align=4</pre><p>Any other section name is treated by default like<code><nobr>.text</nobr></code>.<h3><a name="section-6.4">6.4 <code><nobr>coff</nobr></code>: Common Object File Format</a></h3><p>The <code><nobr>coff</nobr></code> output type produces<code><nobr>COFF</nobr></code> object files suitable for linking with theDJGPP linker.<p><code><nobr>coff</nobr></code> provides a default output file-nameextension of <code><nobr>.o</nobr></code>.<p>The <code><nobr>coff</nobr></code> format supports the same extensionsto the <code><nobr>SECTION</nobr></code> directive as<code><nobr>win32</nobr></code> does, except that the<code><nobr>align</nobr></code> qualifier and the<code><nobr>info</nobr></code> section type are not supported.<h3><a name="section-6.5">6.5 <code><nobr>elf</nobr></code>: Executable and Linkable Format Object Files</a></h3><p>The <code><nobr>elf</nobr></code> output format generates<code><nobr>ELF32</nobr></code> (Executable and Linkable Format) objectfiles, as used by Linux as well as Unix System V, including Solaris x86,UnixWare and SCO Unix. <code><nobr>elf</nobr></code> provides a defaultoutput file-name extension of <code><nobr>.o</nobr></code>.<h4><a name="section-6.5.1">6.5.1 <code><nobr>elf</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a></h4><p>Like the <code><nobr>obj</nobr></code> format,<code><nobr>elf</nobr></code> allows you to specify additional informationon the <code><nobr>SECTION</nobr></code> directive line, to control thetype and properties of sections you declare. Section types and propertiesare generated automatically by NASM for the standard section names<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and<code><nobr>.bss</nobr></code>, but may still be overridden by thesequalifiers.<p>The available qualifiers are:<ul><li><code><nobr>alloc</nobr></code> defines the section to be one which isloaded into memory when the program is run.<code><nobr>noalloc</nobr></code> defines it to be one which is not, suchas an informational or comment section.<li><code><nobr>exec</nobr></code> defines the section to be one whichshould have execute permission when the program is run.<code><nobr>noexec</nobr></code> defines it as one which should not.<li><code><nobr>write</nobr></code> defines the section to be one whichshould be writable when the program is run.<code><nobr>nowrite</nobr></code> defines it as one which should not.<li><code><nobr>progbits</nobr></code> defines the section to be one withexplicit contents stored in the object file: an ordinary code or datasection, for example, <code><nobr>nobits</nobr></code> defines the sectionto be one with no explicit contents given, such as a BSS section.<li><code><nobr>align=</nobr></code>, used with a trailing number as in<code><nobr>obj</nobr></code>, gives the alignment requirements of thesection.</ul><p>The defaults assumed by NASM if you do not specify the above qualifiersare:<p><pre>section .text    progbits  alloc  exec    nowrite  align=16 section .rodata  progbits  alloc  noexec  nowrite  align=4 section .data    progbits  alloc  noexec  write    align=4 section .bss     nobits    alloc  noexec  write    align=4 section other    progbits  alloc  noexec  nowrite  align=1</pre><p>(Any section name other than <code><nobr>.text</nobr></code>,<code><nobr>.rodata</nobr></code>, <code><nobr>.data</nobr></code> and<code><nobr>.bss</nobr></code> is treated by default like<code><nobr>other</nobr></code> in the above code.)<h4><a name="section-6.5.2">6.5.2 Position-Independent Code: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a></h4><p>The <code><nobr>ELF</nobr></code> specification contains enough featuresto allow position-independent code (PIC) to be written, which makes ELFshared libraries very flexible. However, it also means NASM has to be ableto generate a variety of strange relocation types in ELF object files, ifit is to be an assembler which can write PIC.<p>Since <code><nobr>ELF</nobr></code> does not support segment-basereferences, the <code><nobr>WRT</nobr></code> operator is not used for itsnormal purpose; therefore NASM's <code><nobr>elf</nobr></code> outputformat makes use of <code><nobr>WRT</nobr></code> for a different purpose,namely the PIC-specific relocation types.<p><code><nobr>elf</nobr></code> defines five special symbols which you canuse as the right-hand side of the <code><nobr>WRT</nobr></code> operator toobtain PIC relocation types. They are <code><nobr>..gotpc</nobr></code>,<code><nobr>..gotoff</nobr></code>, <code><nobr>..got</nobr></code>,<code><nobr>..plt</nobr></code> and <code><nobr>..sym</nobr></code>. Theirfunctions are summarised here:<ul><li>Referring to the symbol marking the global offset table base using<code><nobr>wrt ..gotpc</nobr></code> will end up giving the distance fromthe beginning of the current section to the global offset table.(<code><nobr>_GLOBAL_OFFSET_TABLE_</nobr></code> is the standard symbolname used to refer to the GOT.) So you would then need to add<code><nobr>$$</nobr></code> to the result to get the real address of theGOT.<li>Referring to a location in one of your own sections using<code><nobr>wrt ..gotoff</nobr></code> will give the distance from thebeginning of the GOT to the specified location, so that adding on theaddress of the GOT would give the real address of the location you wanted.<li>Referring to an external or global symbol using<code><nobr>wrt ..got</nobr></code> causes the linker to build an entry<em>in</em> the GOT containing the address of the symbol, and the referencegives the distance from the beginning of the GOT to the entry; so you canadd on the address of the GOT, load from the resulting address, and end upwith the address of the symbol.<li>Referring to a procedure name using <code><nobr>wrt ..plt</nobr></code>causes the linker to build a procedure linkage table entry for the symbol,and the reference gives the address of the PLT entry. You can only use thisin contexts which would generate a PC-relative relocation normally (i.e. asthe destination for <code><nobr>CALL</nobr></code> or<code><nobr>JMP</nobr></code>), since ELF contains no relocation type torefer to PLT entries absolutely.<li>Referring to a symbol name using <code><nobr>wrt ..sym</nobr></code>causes NASM to write an ordinary relocation, but instead of making therelocation relative to the start of the section and then adding on theoffset to the symbol, it will write a relocation record aimed directly atthe symbol in question. The distinction is a necessary one due to apeculiarity of the dynamic linker.</ul><p>A fuller explanation of how to use these relocation types to writeshared libraries entirely in NASM is given in<a href="nasmdoc8.html#section-8.2">section 8.2</a>.<h4><a name="section-6.5.3">6.5.3 <code><nobr>elf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> Directive</a></h4><p><code><nobr>ELF</nobr></code> object files can contain more informationabout a global symbol than just its address: they can contain the size ofthe symbol and its type as well. These are not merely debuggerconveniences, but are actually necessary when the program being written isa shared library. NASM therefore supports some extensions to the<code><nobr>GLOBAL</nobr></code> directive, allowing you to specify thesefeatures.<p>You can specify whether a global variable is a function or a data objectby suffixing the name with a colon and the word<code><nobr>function</nobr></code> or <code><nobr>data</nobr></code>.(<code><nobr>object</nobr></code> is a synonym for<code><nobr>data</nobr></code>.) For example:<p><pre>global   hashlookup:function, hashtable:data</pre><p>exports the global symbol <code><nobr>hashlookup</nobr></code> as afunction and <code><nobr>hashtable</nobr></code> as a data object.<p>You can also specify the size of the data associated with the symbol, asa numeric expression (which may involve labels, and even forwardreferences) after the type specifier. Like this:<p><pre>