nasmdoc6.htm

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

global  hashtable:data (hashtable.end - hashtable) 

hashtable: 
        db this,that,theother  ; some data here 
.end:
</pre>
<p>This makes NASM automatically calculate the length of the table and
place that information into the <code><nobr>ELF</nobr></code> symbol table.
<p>Declaring the type and size of global symbols is necessary when writing
shared library code. For more information, see
<a href="nasmdoc8.html#section-8.2.4">section 8.2.4</a>.
<h4><a name="section-6.5.4">6.5.4 <code><nobr>elf</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive </a></h4>
<p><code><nobr>ELF</nobr></code> also allows you to specify alignment
requirements on common variables. This is done by putting a number (which
must be a power of two) after the name and size of the common variable,
separated (as usual) by a colon. For example, an array of doublewords would
benefit from 4-byte alignment:
<p><pre>
common  dwordarray 128:4
</pre>
<p>This declares the total size of the array to be 128 bytes, and requires
that it be aligned on a 4-byte boundary.
<h4><a name="section-6.5.5">6.5.5 16-bit code and ELF </a></h4>
<p>The <code><nobr>ELF32</nobr></code> specification doesn't provide
relocations for 8- and 16-bit values, but the GNU
<code><nobr>ld</nobr></code> linker adds these as an extension. NASM can
generate GNU-compatible relocations, to allow 16-bit code to be linked as
ELF using GNU <code><nobr>ld</nobr></code>. If NASM is used with the
<code><nobr>-w+gnu-elf-extensions</nobr></code> option, a warning is issued
when one of these relocations is generated.
<h3><a name="section-6.6">6.6 <code><nobr>aout</nobr></code>: Linux <code><nobr>a.out</nobr></code> Object Files</a></h3>
<p>The <code><nobr>aout</nobr></code> format generates
<code><nobr>a.out</nobr></code> object files, in the form used by early
Linux systems (current Linux systems use ELF, see
<a href="#section-6.5">section 6.5</a>.) These differ from other
<code><nobr>a.out</nobr></code> object files in that the magic number in
the first four bytes of the file is different; also, some implementations
of <code><nobr>a.out</nobr></code>, for example NetBSD's, support
position-independent code, which Linux's implementation does not.
<p><code><nobr>a.out</nobr></code> provides a default output file-name
extension of <code><nobr>.o</nobr></code>.
<p><code><nobr>a.out</nobr></code> is a very simple object format. It
supports no special directives, no special symbols, no use of
<code><nobr>SEG</nobr></code> or <code><nobr>WRT</nobr></code>, and no
extensions to any standard directives. It supports only the three standard
section names <code><nobr>.text</nobr></code>,
<code><nobr>.data</nobr></code> and <code><nobr>.bss</nobr></code>.
<h3><a name="section-6.7">6.7 <code><nobr>aoutb</nobr></code>: NetBSD/FreeBSD/OpenBSD <code><nobr>a.out</nobr></code> Object Files</a></h3>
<p>The <code><nobr>aoutb</nobr></code> format generates
<code><nobr>a.out</nobr></code> object files, in the form used by the
various free <code><nobr>BSD Unix</nobr></code> clones,
<code><nobr>NetBSD</nobr></code>, <code><nobr>FreeBSD</nobr></code> and
<code><nobr>OpenBSD</nobr></code>. For simple object files, this object
format is exactly the same as <code><nobr>aout</nobr></code> except for the
magic number in the first four bytes of the file. However, the
<code><nobr>aoutb</nobr></code> format supports position-independent code
in the same way as the <code><nobr>elf</nobr></code> format, so you can use
it to write <code><nobr>BSD</nobr></code> shared libraries.
<p><code><nobr>aoutb</nobr></code> provides a default output file-name
extension of <code><nobr>.o</nobr></code>.
<p><code><nobr>aoutb</nobr></code> supports no special directives, no
special symbols, and only the three standard section names
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
<code><nobr>.bss</nobr></code>. However, it also supports the same use of
<code><nobr>WRT</nobr></code> as <code><nobr>elf</nobr></code> does, to
provide position-independent code relocation types. See
<a href="#section-6.5.2">section 6.5.2</a> for full documentation of this
feature.
<p><code><nobr>aoutb</nobr></code> also supports the same extensions to the
<code><nobr>GLOBAL</nobr></code> directive as <code><nobr>elf</nobr></code>
does: see <a href="#section-6.5.3">section 6.5.3</a> for documentation of
this.
<h3><a name="section-6.8">6.8 <code><nobr>as86</nobr></code>: Minix/Linux <code><nobr>as86</nobr></code> Object Files</a></h3>
<p>The Minix/Linux 16-bit assembler <code><nobr>as86</nobr></code> has its
own non-standard object file format. Although its companion linker
<code><nobr>ld86</nobr></code> produces something close to ordinary
<code><nobr>a.out</nobr></code> binaries as output, the object file format
used to communicate between <code><nobr>as86</nobr></code> and
<code><nobr>ld86</nobr></code> is not itself
<code><nobr>a.out</nobr></code>.
<p>NASM supports this format, just in case it is useful, as
<code><nobr>as86</nobr></code>. <code><nobr>as86</nobr></code> provides a
default output file-name extension of <code><nobr>.o</nobr></code>.
<p><code><nobr>as86</nobr></code> is a very simple object format (from the
NASM user's point of view). It supports no special directives, no special
symbols, no use of <code><nobr>SEG</nobr></code> or
<code><nobr>WRT</nobr></code>, and no extensions to any standard
directives. It supports only the three standard section names
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
<code><nobr>.bss</nobr></code>.
<h3><a name="section-6.9">6.9 <code><nobr>rdf</nobr></code>: Relocatable Dynamic Object File Format</a></h3>
<p>The <code><nobr>rdf</nobr></code> output format produces
<code><nobr>RDOFF</nobr></code> object files.
<code><nobr>RDOFF</nobr></code> (Relocatable Dynamic Object File Format) is
a home-grown object-file format, designed alongside NASM itself and
reflecting in its file format the internal structure of the assembler.
<p><code><nobr>RDOFF</nobr></code> is not used by any well-known operating
systems. Those writing their own systems, however, may well wish to use
<code><nobr>RDOFF</nobr></code> as their object format, on the grounds that
it is designed primarily for simplicity and contains very little
file-header bureaucracy.
<p>The Unix NASM archive, and the DOS archive which includes sources, both
contain an <code><nobr>rdoff</nobr></code> subdirectory holding a set of
RDOFF utilities: an RDF linker, an <code><nobr>RDF</nobr></code>
static-library manager, an RDF file dump utility, and a program which will
load and execute an RDF executable under Linux.
<p><code><nobr>rdf</nobr></code> supports only the standard section names
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
<code><nobr>.bss</nobr></code>.
<h4><a name="section-6.9.1">6.9.1 Requiring a Library: The <code><nobr>LIBRARY</nobr></code> Directive</a></h4>
<p><code><nobr>RDOFF</nobr></code> contains a mechanism for an object file
to demand a given library to be linked to the module, either at load time
or run time. This is done by the <code><nobr>LIBRARY</nobr></code>
directive, which takes one argument which is the name of the module:
<p><pre>
    library  mylib.rdl
</pre>
<h4><a name="section-6.9.2">6.9.2 Specifying a Module Name: The <code><nobr>MODULE</nobr></code> Directive</a></h4>
<p>Special <code><nobr>RDOFF</nobr></code> header record is used to store
the name of the module. It can be used, for example, by run-time loader to
perform dynamic linking. <code><nobr>MODULE</nobr></code> directive takes
one argument which is the name of current module:
<p><pre>
    module  mymodname
</pre>
<p>Note that when you statically link modules and tell linker to strip the
symbols from output file, all module names will be stripped too. To avoid
it, you should start module names with <code><nobr>$</nobr></code>, like:
<p><pre>
    module  $kernel.core
</pre>
<h4><a name="section-6.9.3">6.9.3 <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> directive</a></h4>
<p><code><nobr>RDOFF</nobr></code> global symbols can contain additional
information needed by the static linker. You can mark a global symbol as
exported, thus telling the linker do not strip it from target executable or
library file. Like in <code><nobr>ELF</nobr></code>, you can also specify
whether an exported symbol is a procedure (function) or data object.
<p>Suffixing the name with a colon and the word
<code><nobr>export</nobr></code> you make the symbol exported:
<p><pre>
    global  sys_open:export
</pre>
<p>To specify that exported symbol is a procedure (function), you add the
word <code><nobr>proc</nobr></code> or <code><nobr>function</nobr></code>
after declaration:
<p><pre>
    global  sys_open:export proc
</pre>
<p>Similarly, to specify exported data object, add the word
<code><nobr>data</nobr></code> or <code><nobr>object</nobr></code> to the
directive:
<p><pre>
    global  kernel_ticks:export data
</pre>
<h3><a name="section-6.10">6.10 <code><nobr>dbg</nobr></code>: Debugging Format</a></h3>
<p>The <code><nobr>dbg</nobr></code> output format is not built into NASM
in the default configuration. If you are building your own NASM executable
from the sources, you can define <code><nobr>OF_DBG</nobr></code> in
<code><nobr>outform.h</nobr></code> or on the compiler command line, and
obtain the <code><nobr>dbg</nobr></code> output format.
<p>The <code><nobr>dbg</nobr></code> format does not output an object file
as such; instead, it outputs a text file which contains a complete list of
all the transactions between the main body of NASM and the output-format
back end module. It is primarily intended to aid people who want to write
their own output drivers, so that they can get a clearer idea of the
various requests the main program makes of the output driver, and in what
order they happen.
<p>For simple files, one can easily use the <code><nobr>dbg</nobr></code>
format like this:
<p><pre>
nasm -f dbg filename.asm
</pre>
<p>which will generate a diagnostic file called
<code><nobr>filename.dbg</nobr></code>. However, this will not work well on
files which were designed for a different object format, because each
object format defines its own macros (usually user-level forms of
directives), and those macros will not be defined in the
<code><nobr>dbg</nobr></code> format. Therefore it can be useful to run
NASM twice, in order to do the preprocessing with the native object format
selected:
<p><pre>
nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i
</pre>
<p>This preprocesses <code><nobr>rdfprog.asm</nobr></code> into
<code><nobr>rdfprog.i</nobr></code>, keeping the
<code><nobr>rdf</nobr></code> object format selected in order to make sure
RDF special directives are converted into primitive form correctly. Then
the preprocessed source is fed through the <code><nobr>dbg</nobr></code>
format to generate the final diagnostic output.
<p>This workaround will still typically not work for programs intended for
<code><nobr>obj</nobr></code> format, because the
<code><nobr>obj</nobr></code> <code><nobr>SEGMENT</nobr></code> and
<code><nobr>GROUP</nobr></code> directives have side effects of defining
the segment and group names as symbols; <code><nobr>dbg</nobr></code> will
not do this, so the program will not assemble. You will have to work around
that by defining the symbols yourself (using
<code><nobr>EXTERN</nobr></code>, for example) if you really need to get a
<code><nobr>dbg</nobr></code> trace of an
<code><nobr>obj</nobr></code>-specific source file.
<p><code><nobr>dbg</nobr></code> accepts any section name and any
directives at all, and logs them all to its output file.
<p align=center><a href="nasmdoc7.html">Next Chapter</a> |
<a href="nasmdoc5.html">Previous Chapter</a> |
<a href="nasmdoc0.html">Contents</a> |
<a href="nasmdoci.html">Index</a>
</body></html>