nasmdoc6.htm

nasm手册 大家可以看看 对要写汇编程序的帮助很大

<p>In addition to these extensions, the <code><nobr>COMMON</nobr></code>
directive in <code><nobr>obj</nobr></code> also supports
default-<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 things
like
<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 Microsoft
Win32 object files, suitable for passing to Microsoft linkers such as
Visual C++. Note that Borland Win32 compilers do not use this format, but
use <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-name
extension 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, the
object files produced by Microsoft Win32 compilers are not compatible with
COFF linkers such as DJGPP's, and vice versa. This is due to a difference
of opinion over the precise semantics of PC-relative relocations. To
produce 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 that
Win32 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 additional
information on the <code><nobr>SECTION</nobr></code> directive line, to
control the type and properties of sections you declare. Section types and
properties are 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 these
qualifiers.
<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, and
also indicates to the linker that the type of the section is code.
<li><code><nobr>data</nobr></code> and <code><nobr>bss</nobr></code> define
the section to be a data section, analogously to
<code><nobr>code</nobr></code>. Data sections are marked as readable and
writable, but not executable. <code><nobr>data</nobr></code> declares an
initialised data section, whereas <code><nobr>bss</nobr></code> declares an
uninitialised data section.
<li><code><nobr>rdata</nobr></code> declares an initialised data section
that is readable but not writable. Microsoft compilers use this section to
place constants in it.
<li><code><nobr>info</nobr></code> defines the section to be an
informational section, which is not included in the executable file by the
linker, but may (for example) pass information <em>to</em> the linker. For
example, declaring an <code><nobr>info</nobr></code>-type section called
<code><nobr>.drectve</nobr></code> causes the linker to interpret the
contents 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 the
section. The maximum you may specify is 64: the Win32 object file format
contains no means to request a greater section alignment than this. If
alignment is not explicitly specified, the defaults are 16-byte alignment
for code sections, 8-byte alignment for rdata sections and 4-byte alignment
for data (and BSS) sections. Informational sections get a default alignment
of 1 byte (no alignment), though the value does not matter.
</ul>
<p>The defaults assumed by NASM if you do not specify the above qualifiers
are:
<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 the
DJGPP linker.
<p><code><nobr>coff</nobr></code> provides a default output file-name
extension of <code><nobr>.o</nobr></code>.
<p>The <code><nobr>coff</nobr></code> format supports the same extensions
to 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) object
files, as used by Linux as well as Unix System V, including Solaris x86,
UnixWare and SCO Unix. <code><nobr>elf</nobr></code> provides a default
output 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 information
on the <code><nobr>SECTION</nobr></code> directive line, to control the
type and properties of sections you declare. Section types and properties
are 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 these
qualifiers.
<p>The available qualifiers are:
<ul>
<li><code><nobr>alloc</nobr></code> defines the section to be one which is
loaded into memory when the program is run.
<code><nobr>noalloc</nobr></code> defines it to be one which is not, such
as an informational or comment section.
<li><code><nobr>exec</nobr></code> defines the section to be one which
should 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 which
should 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 with
explicit contents stored in the object file: an ordinary code or data
section, for example, <code><nobr>nobits</nobr></code> defines the section
to 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 the
section.
</ul>
<p>The defaults assumed by NASM if you do not specify the above qualifiers
are:
<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 features
to allow position-independent code (PIC) to be written, which makes ELF
shared libraries very flexible. However, it also means NASM has to be able
to generate a variety of strange relocation types in ELF object files, if
it is to be an assembler which can write PIC.
<p>Since <code><nobr>ELF</nobr></code> does not support segment-base
references, the <code><nobr>WRT</nobr></code> operator is not used for its
normal purpose; therefore NASM's <code><nobr>elf</nobr></code> output
format 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 can
use as the right-hand side of the <code><nobr>WRT</nobr></code> operator to
obtain 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>. Their
functions 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 from
the beginning of the current section to the global offset table.
(<code><nobr>_GLOBAL_OFFSET_TABLE_</nobr></code> is the standard symbol
name 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 the
GOT.
<li>Referring to a location in one of your own sections using
<code><nobr>wrt ..gotoff</nobr></code> will give the distance from the
beginning of the GOT to the specified location, so that adding on the
address 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 reference
gives the distance from the beginning of the GOT to the entry; so you can
add on the address of the GOT, load from the resulting address, and end up
with 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 this
in contexts which would generate a PC-relative relocation normally (i.e. as
the destination for <code><nobr>CALL</nobr></code> or
<code><nobr>JMP</nobr></code>), since ELF contains no relocation type to
refer 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 the
relocation relative to the start of the section and then adding on the
offset to the symbol, it will write a relocation record aimed directly at
the symbol in question. The distinction is a necessary one due to a
peculiarity of the dynamic linker.
</ul>
<p>A fuller explanation of how to use these relocation types to write
shared 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 information
about a global symbol than just its address: they can contain the size of
the symbol and its type as well. These are not merely debugger
conveniences, but are actually necessary when the program being written is
a shared library. NASM therefore supports some extensions to the
<code><nobr>GLOBAL</nobr></code> directive, allowing you to specify these
features.
<p>You can specify whether a global variable is a function or a data object
by 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 a
function and <code><nobr>hashtable</nobr></code> as a data object.
<p>You can also specify the size of the data associated with the symbol, as
a numeric expression (which may involve labels, and even forward
references) after the type specifier. Like this:
<p><pre>