Next Chapter | Previous Chapter | Contents | Index
NASM is a portable assembler, designed to be able to compile on any ANSI
C-supporting platform and produce output to run on a variety of Intel x86
operating systems. For this reason, it has a large number of available
output formats, selected using the
option on
the NASM command line. Each of these formats, along with its extensions to
the base NASM syntax, is detailed in this chapter.
As stated in section 2.1.1,
NASM chooses a default name for your output file based on the input file
name and the chosen output format. This will be generated by removing the
extension (
,
, or
whatever you like to use) from the input file name, and substituting an
extension defined by the output format. The extensions are given with each
format below.
bin
: Flat-Form Binary OutputThe
format does not produce object files:
it generates nothing in the output file except the code you wrote. Such
`pure binary' files are used by MS-DOS:
executables and
device drivers are pure
binary files. Pure binary output is also useful for operating-system and
boot loader development.
supports the three standardised section
names
,
and
only. The file NASM outputs will contain the
contents of the
section first, followed by
the contents of the
section, aligned on a
four-byte boundary. The
section is not
stored in the output file at all, but is assumed to appear directly after
the end of the
section, again aligned on a
four-byte boundary.
If you specify no explicit
directive,
the code you write will be directed by default into the
section.
Using the
format puts NASM by default into
16-bit mode (see section 5.1). In
order to use
to write 32-bit code such as an
OS kernel, you need to explicitly issue the
directive.
has no default output file name extension:
instead, it leaves your file name as it is once the original extension has
been removed. Thus, the default is for NASM to assemble
into a binary file called
.
ORG
: Binary File Program OriginThe
format provides an additional
directive to the list given in chapter 5:
. The function of the
directive is to specify the origin address
which NASM will assume the program begins at when it is loaded into memory.
For example, the following code will generate the longword
:
org 0x100 dd label label:
Unlike the
directive provided by
MASM-compatible assemblers, which allows you to jump around in the object
file and overwrite code you have already generated, NASM's
does exactly what the directive says:
origin. Its sole function is to specify one offset which is added
to all internal address references within the file; it does not permit any
of the trickery that MASM's version does. See
section 10.1.3 for further
comments.
bin
Extensions to the SECTION
DirectiveThe
output format extends the
(or
)
directive to allow you to specify the alignment requirements of segments.
This is done by appending the
qualifier to
the end of the section-definition line. For example,
section .data align=16
switches to the section
and also
specifies that it must be aligned on a 16-byte boundary.
The parameter to
specifies how many low
bits of the section start address must be forced to zero. The alignment
value given may be any power of two.
obj
: Microsoft OMF Object FilesThe
file format (NASM calls it
rather than
for
historical reasons) is the one produced by MASM and TASM, which is
typically fed to 16-bit DOS linkers to produce
files. It is also the format used by OS/2.
provides a default output file-name
extension of
.
is not exclusively a 16-bit format,
though: NASM has full support for the 32-bit extensions to the format. In
particular, 32-bit
format files are used by
Borland's Win32 compilers, instead of using Microsoft's newer
object file format.
The
format does not define any special
segment names: you can call your segments anything you like. Typical names
for segments in
format files are
,
and
.
If your source file contains code before specifying an explicit
directive, then NASM will invent its own
segment called
for you.
When you define a segment in an
file, NASM
defines the segment name as a symbol as well, so that you can access the
segment address of the segment. So, for example:
segment data dvar: dw 1234 segment code function: mov ax,data ; get segment address of data mov ds,ax ; and move it into DS inc word [dvar] ; now this reference will work ret
The
format also enables the use of the
and
operators,
so that you can write code which does things like
extern foo mov ax,seg foo ; get preferred segment of foo mov ds,ax mov ax,data ; a different segment mov es,ax mov ax,[ds:foo] ; this accesses `foo' mov [es:foo wrt data],bx ; so does this
obj
Extensions to the SEGMENT
DirectiveThe
output format extends the
(or
)
directive to allow you to specify various properties of the segment you are
defining. This is done by appending extra qualifiers to the end of the
segment-definition line. For example,
segment code private align=16
defines the segment
, but also declares it
to be a private segment, and requires that the portion of it described in
this code module must be aligned on a 16-byte boundary.
The available qualifiers are:
PRIVATE
, PUBLIC
,
COMMON
and STACK
specify the combination characteristics of the segment.
PRIVATE
segments do not get combined with any
others by the linker; PUBLIC
and
STACK
segments get concatenated together at link
time; and COMMON
segments all get overlaid on top
of each other rather than stuck end-to-end.
ALIGN
is used, as shown above, to specify how
many low bits of the segment start address must be forced to zero. The
alignment value given may be any power of two from 1 to 4096; in reality,
the only values supported are 1, 2, 4, 16, 256 and 4096, so if 8 is
specified it will be rounded up to 16, and 32, 64 and 128 will all be
rounded up to 256, and so on. Note that alignment to 4096-byte boundaries
is a PharLap extension to the format and may not be supported by all
linkers.
CLASS
can be used to specify the segment
class; this feature indicates to the linker that segments of the same class
should be placed near each other in the output file. The class name can be
any word, e.g. CLASS=CODE
.
OVERLAY
, like
CLASS
, is specified with an arbitrary word as an
argument, and provides overlay information to an overlay-capable linker.
USE16
or
USE32
, which has the effect of recording the
choice in the object file and also ensuring that NASM's default assembly
mode when assembling in that segment is 16-bit or 32-bit respectively.
FLAT
, which causes the default segment base for
anything in the segment to be the special group
FLAT
, and also defines the group if it is not
already defined.
obj
file format also allows segments to
be declared as having a pre-defined absolute segment address, although no
linkers are currently known to make sensible use of this feature;
nevertheless, NASM allows you to declare a segment such as
SEGMENT SCREEN ABSOLUTE=0xB800
if you need to.
The ABSOLUTE
and ALIGN
keywords are mutually exclusive.
NASM's default segment attributes are
,
, no class, no overlay, and
.
GROUP
: Defining Groups of SegmentsThe
format also allows segments to be
grouped, so that a single segment register can be used to refer to all the
segments in a group. NASM therefore supplies the
directive, whereby you can code
segment data ; some data segment bss ; some uninitialised data group dgroup data bss
which will define a group called
to
contain the segments
and
. Like
,
causes the group name to be defined as a
symbol, so that you can refer to a variable
in the
segment as
or as
, depending on which segment value
is currently in your segment register.
If you just refer to
, however, and
is declared in a segment which is part of a
group, then NASM will default to giving you the offset of
from the beginning of the group, not
the segment. Therefore
, also,
will return the group base rather than the segment base.
NASM will allow a segment to be part of more than one group, but will generate a warning if you do this. Variables declared in a segment which is part of more than one group will default to being relative to the first group that was defined to contain the segment.
A group does not have to contain any segments; you can still make
references to a group which does not contain
the variable you are referring to. OS/2, for example, defines the special
group
with no segments in it.
UPPERCASE
: Disabling Case Sensitivity in OutputAlthough NASM itself is case sensitive, some OMF linkers are not;
therefore it can be useful for NASM to output single-case object files. The
format-specific directive causes all
segment, group and symbol names that are written to the object file to be
forced to upper case just before being written. Within a source file, NASM
is still case-sensitive; but the object file can be written entirely in
upper case if desired.
is used alone on a line; it requires
no parameters.
IMPORT
: Importing DLL SymbolsThe
format-specific directive defines a
symbol to be imported from a DLL, for use if you are writing a DLL's import
library in NASM. You still need to declare the symbol as
as well as using the
directive.
The
directive takes two required
parameters, separated by white space, which are (respectively) the name of
the symbol you wish to import and the name of the library you wish to
import it from. For example:
import WSAStartup wsock32.dll
A third optional parameter gives the name by which the symbol is known in the library you are importing it from, in case this is not the same as the name you wish the symbol to be known by to your code once you have imported it. For example:
import asyncsel wsock32.dll WSAAsyncSelect
EXPORT
: Exporting DLL SymbolsThe
format-specific directive defines a
global symbol to be exported as a DLL symbol, for use if you are writing a
DLL in NASM. You still need to declare the symbol as
as well as using the
directive.
takes one required parameter, which is
the name of the symbol you wish to export, as it was defined in your source
file. An optional second parameter (separated by white space from the
first) gives the external name of the symbol: the name by which
you wish the symbol to be known to programs using the DLL. If this name is
the same as the internal name, you may leave the second parameter off.
Further parameters can be given to define attributes of the exported symbol. These parameters, like the second, are separated by white space. If further parameters are given, the external name must also be specified, even if it is the same as the internal name. The available attributes are:
resident
indicates that the exported name is
to be kept resident by the system loader. This is an optimisation for
frequently used symbols imported by name.
nodata
indicates that the exported symbol is
a function which does not make use of any initialised data.
parm=NNN
, where NNN
is an integer, sets the number of parameter words for the case in which the
symbol is a call gate between 32-bit and 16-bit segments.
For example:
export myfunc export myfunc TheRealMoreFormalLookingFunctionName export myfunc myfunc 1234 ; export by ordinal export myfunc myfunc resident parm=23 nodata
..start
: Defining the Program Entry PointOMF linkers require exactly one of the object files being linked to
define the program entry point, where execution will begin when the program
is run. If the object file that defines the entry point is assembled using
NASM, you specify the entry point by declaring the special symbol
at the point where you wish execution to
begin.
obj
Extensions to the EXTERN
DirectiveIf you declare an external symbol with the directive
extern foo
then references such as
will give
you the offset of
from its preferred segment
base (as specified in whichever module
is
actually defined in). So to access the contents of
you will usually need to do something like
mov ax,seg foo ; get preferred segment base mov es,ax ; move it into ES mov ax,[es:foo] ; and use offset `foo' from it
This is a little unwieldy, particularly if you know that an external is
going to be accessible from a given segment or group, say
. So if
already contained
, you could simply code
mov ax,[foo wrt dgroup]
However, having to type this every time you want to access
can be a pain; so NASM allows you to declare
in the alternative form
extern foo:wrt dgroup
This form causes NASM to pretend that the preferred segment base of
is in fact
;
so the expression
will now return
, and the expression
is equivalent to
.
This default-
mechanism can be used to make
externals appear to be relative to any group or segment in your program. It
can also be applied to common variables: see
section 6.2.8.
obj
Extensions to the COMMON
DirectiveThe
format allows common variables to be
either near or far; NASM allows you to specify which your variables should
be by the use of the syntax
common nearvar 2:near ; `nearvar' is a near common common farvar 10:far ; and `farvar' is far
Far common variables may be greater in size than 64Kb, and so the OMF specification says that they are declared as a number of elements of a given size. So a 10-byte far common variable could be declared as ten one-byte elements, five two-byte elements, two five-byte elements or one ten-byte element.
Some OMF linkers require the element size, as well as the variable size, to match when resolving common variables declared in more than one module. Therefore NASM must allow you to specify the element size on your far common variables. This is done by the following syntax:
common c_5by2 10:far 5 ; two five-byte elements common c_2by5 10:far 2 ; five two-byte elements
If no element size is specified, the default is 1. Also, the
keyword is not required when an element size
is specified, since only far commons may have element sizes at all. So the
above declarations could equivalently be
common c_5by2 10:5 ; two five-byte elements common c_2by5 10:2 ; five two-byte elements
In addition to these extensions, the
directive in
also supports
default-
specification like
does (explained in
section 6.2.7). So you can also declare things
like
common foo 10:wrt dgroup common bar 16:far 2:wrt data common baz 24:wrt data:6
win32
: Microsoft Win32 Object FilesThe
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
instead (see
section 6.2).
provides a default output file-name
extension of
.
Note that although Microsoft say that Win32 object files follow the COFF
(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
output
format; conversely, the
format does not
produce object files that Win32 linkers can generate correct output from.
win32
Extensions to the SECTION
DirectiveLike the
format,
allows you to specify additional
information on the
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
,
and
, but may still be overridden by these
qualifiers.
The available qualifiers are:
code
, or equivalently
text
, 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.
data
and bss
define
the section to be a data section, analogously to
code
. Data sections are marked as readable and
writable, but not executable. data
declares an
initialised data section, whereas bss
declares an
uninitialised data section.
info
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 to the linker. For
example, declaring an info
-type section called
.drectve
causes the linker to interpret the
contents of the section as command-line options.
align=
, used with a trailing number as in
obj
, 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, 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.
The defaults assumed by NASM if you do not specify the above qualifiers are:
section .text code align=16 section .data data align=4 section .bss bss align=4
Any other section name is treated by default like
.
coff
: Common Object File FormatThe
output type produces COFF object
files suitable for linking with the DJGPP linker.
provides a default output file-name
extension of
.
The
format supports the same extensions
to the
directive as
does, except that the
qualifier and the
section type are not supported.
elf
: Linux ELFObject FilesThe
output format generates ELF32
(Executable and Linkable Format) object files, as used by Linux.
provides a default output file-name extension
of
.
elf
Extensions to the SECTION
DirectiveLike the
format,
allows you to specify additional information
on the
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
,
and
, but may still be overridden by these
qualifiers.
The available qualifiers are:
alloc
defines the section to be one which is
loaded into memory when the program is run.
noalloc
defines it to be one which is not, such
as an informational or comment section.
exec
defines the section to be one which
should have execute permission when the program is run.
noexec
defines it as one which should not.
write
defines the section to be one which
should be writable when the program is run.
nowrite
defines it as one which should not.
progbits
defines the section to be one with
explicit contents stored in the object file: an ordinary code or data
section, for example, nobits
defines the section
to be one with no explicit contents given, such as a BSS section.
align=
, used with a trailing number as in
obj
, gives the alignment requirements of the
section.
The defaults assumed by NASM if you do not specify the above qualifiers are:
section .text progbits alloc exec nowrite align=16 section .data progbits alloc noexec write align=4 section .bss nobits alloc noexec write align=4 section other progbits alloc noexec nowrite align=1
(Any section name other than
,
and
is
treated by default like
in the above code.)
elf
Special Symbols and WRT
The ELF 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.
Since ELF does not support segment-base references, the
operator is not used for its normal purpose;
therefore NASM's
output format makes use of
for a different purpose, namely the
PIC-specific relocation types.
defines five special symbols which you can
use as the right-hand side of the
operator to
obtain PIC relocation types. They are
,
,
,
and
. Their
functions are summarised here:
wrt ..gotpc
will end up giving the distance from
the beginning of the current section to the global offset table.
(_GLOBAL_OFFSET_TABLE_
is the standard symbol
name used to refer to the GOT.) So you would then need to add
$$
to the result to get the real address of the
GOT.
wrt ..gotoff
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.
wrt ..got
causes the linker to build an entry
in 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.
wrt ..plt
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 CALL
or
JMP
), since ELF contains no relocation type to
refer to PLT entries absolutely.
wrt ..sym
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.
A fuller explanation of how to use these relocation types to write shared libraries entirely in NASM is given in section 8.2.
elf
Extensions to the GLOBAL
DirectiveELF 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
directive, allowing you to specify these features.
You can specify whether a global variable is a function or a data object
by suffixing the name with a colon and the word
or
.
(
is a synonym for
.) For example:
global hashlookup:function, hashtable:data
exports the global symbol
as a
function and
as a data object.
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:
global hashtable:data (hashtable.end - hashtable) hashtable: db this,that,theother ; some data here .end:
This makes NASM automatically calculate the length of the table and place that information into the ELF symbol table.
Declaring the type and size of global symbols is necessary when writing shared library code. For more information, see section 8.2.4.
elf
Extensions to the COMMON
DirectiveELF 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:
common dwordarray 128:4
This declares the total size of the array to be 128 bytes, and requires that it be aligned on a 4-byte boundary.
aout
: Linux a.out
Object FilesThe
format generates
object files, in the form used by early
Linux systems. (These differ from other
object files in that the magic number in the first four bytes of the file
is different. Also, some implementations of
, for example NetBSD's, support
position-independent code, which Linux's implementation doesn't.)
provides a default output file-name
extension of
.
is a very simple object format. It
supports no special directives, no special symbols, no use of
or
, and no
extensions to any standard directives. It supports only the three standard
section names
,
and
.
aoutb
: NetBSD/FreeBSD/OpenBSD a.out
Object FilesThe
format generates
object files, in the form used by the
various free BSD Unix clones, NetBSD, FreeBSD and OpenBSD. For simple
object files, this object format is exactly the same as
except for the magic number in the first
four bytes of the file. However, the
format
supports position-independent code in the same way as the
format, so you can use it to write BSD shared
libraries.
provides a default output file-name
extension of
.
supports no special directives, no
special symbols, and only the three standard section names
,
and
. However, it also supports the same use of
as
does, to
provide position-independent code relocation types. See
section 6.5.2 for full documentation of this
feature.
also supports the same extensions to the
directive as
does: see section 6.5.3 for documentation of
this.
as86
: Linux as86
Object FilesThe Linux 16-bit assembler
has its own
non-standard object file format. Although its companion linker
produces something close to ordinary
binaries as output, the object file format
used to communicate between
and
is not itself
.
NASM supports this format, just in case it is useful, as
.
provides a
default output file-name extension of
.
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
or
, and no extensions to any standard
directives. It supports only the three standard section names
,
and
.
rdf
: Relocatable Dynamic Object File FormatThe
output format produces RDOFF object
files. RDOFF (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.
RDOFF is not used by any well-known operating systems. Those writing their own systems, however, may well wish to use RDOFF as their object format, on the grounds that it is designed primarily for simplicity and contains very little file-header bureaucracy.
The Unix NASM archive, and the DOS archive which includes sources, both
contain an
subdirectory holding a set of
RDOFF utilities: an RDF linker, an RDF static-library manager, an RDF file
dump utility, and a program which will load and execute an RDF executable
under Linux.
supports only the standard section names
,
and
.
LIBRARY
DirectiveRDOFF 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
directive, which takes one
argument which is the name of the module:
library mylib.rdl
dbg
: Debugging FormatThe
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
in
or on the compiler command line, and
obtain the
output format.
The
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.
For simple files, one can easily use the
format like this:
nasm -f dbg filename.asm
which will generate a diagnostic file called
. 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
format. Therefore it can be useful to run
NASM twice, in order to do the preprocessing with the native object format
selected:
nasm -e -f rdf -o rdfprog.i rdfprog.asm nasm -a -f dbg rdfprog.i
This preprocesses
into
, keeping the
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
format to generate the final diagnostic output.
This workaround will still typically not work for programs intended for
format, because the
and
directives have side effects of defining
the segment and group names as symbols;
will
not do this, so the program will not assemble. You will have to work around
that by defining the symbols yourself (using
, for example) if you really need to get a
trace of an
-specific source file.
accepts any section name and any
directives at all, and logs them all to its output file.