* Expressions:: Expressions
* Pseudo Ops:: Assembler Directives
* Machine Dependencies:: Machine Dependent Features
+* Reporting Bugs:: Reporting Bugs
* Acknowledgements:: Who Did What
* Index:: Index
@end menu
[ -mbig-endian | -mlittle-endian ]
@end ifset
@c end-sanitize-arc
+@c start-sanitize-d10v
+@ifset D10V
+ [ -O ]
+@end ifset
+@c end-sanitize-d10v
+
@ifset H8
@c Hitachi family chips have no machine-dependent assembler options
@end ifset
@end table
@end ifset
+@c start-sanitize-d10v
+@ifset D10V
+The following options are available when @value{AS} is configured for
+a D10V processor.
+@table @code
+@cindex D10V optimization
+@cindex optimization, D10V
+@item -O
+Optimize output by parallelizing instructions.
+@end table
+@end ifset
+@c end-sanitize-d10v
+
@ifset I960
The following options are available when @value{AS} is configured for the
Intel 80960 processor.
@item -l
Shorten references to undefined symbols, to one word instead of two.
-@item -m68000 | -m68008 | -m68010 | -m68020 | -m68030 | -m68040
-@itemx | -m68302 | -m68331 | -m68332 | -m68333 | -m68340 | -mcpu32
+@item -m68000 | -m68008 | -m68010 | -m68020 | -m68030 | -m68040 | -m68060
+@itemx | -m68302 | -m68331 | -m68332 | -m68333 | -m68340 | -mcpu32 | -m5200
Specify what processor in the 68000 family is the target. The default
is normally the 68020, but this can be changed at configuration time.
compatible with the @code{ASM68K} or the @code{ASM960} (depending upon the
configured target) assembler from Microtec Research. The exact nature of the
MRI syntax will not be documented here; see the MRI manuals for more
-information. The purpose of this option is to permit assembling existing MRI
-assembler code using @code{@value{AS}}.
+information. Note in particular that the handling of macros and macro
+arguments is somewhat different. The purpose of this option is to permit
+assembling existing MRI assembler code using @code{@value{AS}}.
The MRI compatibility is not complete. Certain operations of the MRI assembler
depend upon its object file format, and can not be supported using other object
@cindex line comment character
Anything from the @dfn{line comment} character to the next newline
is considered a comment and is ignored. The line comment character is
+@ifset A29K
+@samp{;} for the AMD 29K family;
+@end ifset
@c start-sanitize-arc
@ifset ARC
@samp{;} on the ARC;
@end ifset
@c end-sanitize-arc
-@ifset VAX
-@samp{#} on the Vax;
-@end ifset
-@ifset I960
-@samp{#} on the i960;
-@end ifset
-@ifset SPARC
-@samp{!} on the SPARC;
-@end ifset
-@ifset M680X0
-@samp{|} on the 680x0;
-@end ifset
-@ifset A29K
-@samp{;} for the AMD 29K family;
-@end ifset
@ifset H8/300
@samp{;} for the H8/300 family;
@end ifset
@ifset HPPA
@samp{;} for the HPPA;
@end ifset
+@ifset I960
+@samp{#} on the i960;
+@end ifset
@ifset SH
@samp{!} for the Hitachi SH;
@end ifset
+@ifset SPARC
+@samp{!} on the SPARC;
+@end ifset
+@ifset M680X0
+@samp{|} on the 680x0;
+@end ifset
+@ifset VAX
+@samp{#} on the Vax;
+@end ifset
@ifset Z8000
@samp{!} for the Z8000;
@end ifset
For compatibility with other Unix systems, 8 and 9 are accepted as digits:
for example, @code{\008} has the value 010, and @code{\009} the value 011.
-@ifset HPPA
-@cindex @code{\@var{xdd}} (hex character code)
-@cindex hex character code (@code{\@var{xdd}})
-@item \@code{x} @var{hex-digit} @var{hex-digit}
-A hex character code. The numeric code is 2 hexadecimal digits. Either
-upper or lower case @code{x} works.
-@end ifset
+@cindex @code{\@var{xd...}} (hex character code)
+@cindex hex character code (@code{\@var{xd...}})
+@item \@code{x} @var{hex-digits...}
+A hex character code. All trailing hex digits are combined. Either upper or
+lower case @code{x} works.
@cindex @code{\\} (@samp{\} character)
@cindex backslash (@code{\\})
@ifset H8
One of the letters @samp{DFPRSX} (in upper or lower case).
@end ifset
-@ifset I960
-One of the letters @samp{DFT} (in upper or lower case).
-@end ifset
@ifset HPPA
The letter @samp{E} (upper case only).
@end ifset
+@ifset I960
+One of the letters @samp{DFT} (in upper or lower case).
+@end ifset
@end ifclear
@item
@end ifclear
* Ln:: @code{.ln @var{line-number}}
+* Linkonce:: @code{.linkonce [@var{type}]}
* List:: @code{.list}
* Long:: @code{.long @var{expressions}}
@ignore
@end ignore
* Macro:: @code{.macro @var{name} @var{args}}@dots{}
+* MRI:: @code{.mri @var{val}}
* Nolist:: @code{.nolist}
* Octa:: @code{.octa @var{bignums}}
* Size:: @code{.size}
@end ifset
+* Skip:: @code{.skip @var{size} , @var{fill}}
* Space:: @code{.space @var{size} , @var{fill}}
@ifset have-stabs
* Stab:: @code{.stabd, .stabn, .stabs}
alignment required, as described below.
The second expression (also absolute) gives the value to be stored in
the padding bytes. It (and the comma) may be omitted. If it is
-omitted, the padding bytes are zero.
+omitted, the padding bytes are zero.
+For the alpha, if the section is marked as containing code and the
+padding expression is omitted, then the space is filled with no-ops.
The way the required alignment is specified varies from system to system.
-For the a29k, hppa, m86k, m88k, w65, sparc, and Hitachi SH, and i386 using ELF
+For the a29k, hppa, m68k, m88k, w65, sparc, and Hitachi SH, and i386 using ELF
format,
the first expression is the
alignment request in bytes. For example @samp{.align 8} advances
(which must be an @var{absolute expression}) is non-zero. The end of
the conditional section of code must be marked by @code{.endif}
(@pxref{Endif,,@code{.endif}}); optionally, you may include code for the
-alternative condition, flagged by @code{.else} (@pxref{Else,,@code{.else}}.
+alternative condition, flagged by @code{.else} (@pxref{Else,,@code{.else}}).
The following variants of @code{.if} are also supported:
@table @code
@cindex @code{ifndef} directive
@cindex @code{ifnotdef} directive
@item .ifndef @var{symbol}
-@itemx ifnotdef @var{symbol}
+@itemx .ifnotdef @var{symbol}
Assembles the following section of code if the specified @var{symbol}
has not been defined. Both spelling variants are equivalent.
debugging.
@end ifclear
+@node Linkonce
+@section @code{.linkonce [@var{type}]}
+@cindex COMDAT
+@cindex @code{linkonce} directive
+@cindex common sections
+Mark the current section so that the linker only includes a single copy of it.
+This may be used to include the same section in several different object files,
+but ensure that the linker will only include it once in the final output file.
+The @code{.linkonce} pseudo-op must be used for each instance of the section.
+Duplicate sections are detected based on the section name, so it should be
+unique.
+
+This directive is only supported by a few object file formats; as of this
+writing, the only object file format which supports it is the Portable
+Executable format used on Windows NT.
+
+The @var{type} argument is optional. If specified, it must be one of the
+following strings. For example:
+@smallexample
+.linkonce same_size
+@end smallexample
+Not all types may be supported on all object file formats.
+
+@table @code
+@item discard
+Silently discard duplicate sections. This is the default.
+
+@item one_only
+Warn if there are duplicate sections, but still keep only one copy.
+
+@item same_size
+Warn if any of the duplicates have different sizes.
+
+@item same_contents
+Warn if any of the duplicates do not have exactly the same contents.
+@end table
+
@node Ln
@section @code{.ln @var{line-number}}
@end ifset
@end ifset
+@node MRI
+@section @code{.mri @var{val}}
+
+@cindex @code{mri} directive
+@cindex MRI mode, temporarily
+If @var{val} is non-zero, this tells @code{@value{AS}} to enter MRI mode. If
+@var{val} is zero, this tells @code{@value{AS}} to exit MRI mode. This change
+affects code assembled until the next @code{.mri} directive, or until the end
+of the file. @xref{M, MRI mode, MRI mode}.
+
@node List
@section @code{.list}
@end ifset
@end ifset
-@ifset COFF
@node Section
-@section @code{.section @var{name}, @var{subsection}}
+@section @code{.section @var{name}}
@cindex @code{section} directive
-@cindex named section (COFF)
-@cindex COFF named section
-Assemble the following code into end of subsection numbered
-@var{subsection} in the COFF named section @var{name}. If you omit
-@var{subsection}, @code{@value{AS}} uses subsection number zero.
-@samp{.section .text} is equivalent to the @code{.text} directive;
-@samp{.section .data} is equivalent to the @code{.data} directive.
-@ifset GENERIC
+@cindex named section
+Use the @code{.section} directive to assemble the following code into a section
+named @var{name}.
+
This directive is only supported for targets that actually support arbitrarily
named sections; on @code{a.out} targets, for example, it is not accepted, even
-with a standard @code{a.out} section name as its parameter.
+with a standard @code{a.out} section name.
+
+@ifset COFF
+For COFF targets, the @code{.section} directive is used in one of the following
+ways:
+@smallexample
+.section @var{name}[, "@var{flags}"]
+.section @var{name}[, @var{subsegment}]
+@end smallexample
+
+If the optional argument is quoted, it is taken as flags to use for the
+section. Each flag is a single character. The following flags are recognized:
+@table @code
+@item b
+bss section (uninitialized data)
+@item n
+section is not loaded
+@item w
+writable section
+@item d
+data section
+@item x
+executable section
+@end table
+
+If no flags are specified, the default flags depend upon the section name. If
+the section name is not recognized, the default will be for the section to be
+loaded and writable.
+
+If the optional argument to the @code{.section} directive is not quoted, it is
+taken as a subsegment number (@pxref{Sub-Sections}).
@end ifset
+
+@ifset ELF
+For ELF targets, the @code{.section} directive is used like this:
+@smallexample
+.section @var{name}[, "@var{flags}"[, @@@var{type}]]
+@end smallexample
+The optional @var{flags} argument is a quoted string which may contain any
+combintion of the following characters:
+@table @code
+@item a
+section is allocatable
+@item w
+section is writable
+@item x
+section is executable
+@end table
+
+The optional @var{type} argument may contain one of the following constants:
+@table @code
+@item @@progbits
+section contains data
+@item @@nobits
+section does not contain data (i.e., section only occupies space)
+@end table
+
+If no flags are specified, the default flags depend upon the section name. If
+the section name is not recognized, the default will be for the section to have
+none of the above flags: it will not be allocated in memory, nor writable, nor
+executable. The section will contain data.
+
+For ELF targets, the assembler supports another type of @code{.section}
+directive for compatibility with the Solaris assembler:
+@smallexample
+.section "@var{name}"[, @var{flags}...]
+@end smallexample
+Note that the section name is quoted. There may be a sequence of comma
+separated flags:
+@table @code
+@item #alloc
+section is allocatable
+@item #write
+section is writable
+@item #execinstr
+section is executable
+@end table
@end ifset
@node Set
@end ifset
@ifclear no-space-dir
+@node Skip
+@section @code{.skip @var{size} , @var{fill}}
+
+@cindex @code{skip} directive
+@cindex filling memory
+This directive emits @var{size} bytes, each of value @var{fill}. Both
+@var{size} and @var{fill} are absolute expressions. If the comma and
+@var{fill} are omitted, @var{fill} is assumed to be zero. This is the same as
+@samp{.space}.
+
@node Space
@section @code{.space @var{size} , @var{fill}}
@cindex filling memory
This directive emits @var{size} bytes, each of value @var{fill}. Both
@var{size} and @var{fill} are absolute expressions. If the comma
-and @var{fill} are omitted, @var{fill} is assumed to be zero.
+and @var{fill} are omitted, @var{fill} is assumed to be zero. This is the same
+as @samp{.skip}.
@ifset HPPA
@quotation
subject, see the hardware manufacturer's manual.
@menu
+@ifset A29K
+* AMD29K-Dependent:: AMD 29K Dependent Features
+@end ifset
@c start-sanitize-arc
@ifset ARC
* ARC-Dependent:: ARC Dependent Features
@end ifset
@c end-sanitize-arc
-@ifset VAX
-* Vax-Dependent:: VAX Dependent Features
-@end ifset
-@ifset A29K
-* AMD29K-Dependent:: AMD 29K Dependent Features
+@c start-sanitize-d10v
+@ifset D10V
+* D10V-Dependent:: D10V Dependent Features
@end ifset
+@c end-sanitize-d10v
@ifset H8/300
* H8/300-Dependent:: Hitachi H8/300 Dependent Features
@end ifset
@ifset HPPA
* HPPA-Dependent:: HPPA Dependent Features
@end ifset
-@ifset SH
-* SH-Dependent:: Hitachi SH Dependent Features
+@ifset I80386
+* i386-Dependent:: Intel 80386 Dependent Features
@end ifset
@ifset I960
* i960-Dependent:: Intel 80960 Dependent Features
@ifset M680X0
* M68K-Dependent:: M680x0 Dependent Features
@end ifset
+@ifset MIPS
+* MIPS-Dependent:: MIPS Dependent Features
+@end ifset
+@ifset SH
+* SH-Dependent:: Hitachi SH Dependent Features
+@end ifset
@ifset SPARC
* Sparc-Dependent:: SPARC Dependent Features
@end ifset
@ifset Z8000
* Z8000-Dependent:: Z8000 Dependent Features
@end ifset
-@ifset MIPS
-* MIPS-Dependent:: MIPS Dependent Features
-@end ifset
-@ifset I80386
-* i386-Dependent:: 80386 Dependent Features
+@ifset VAX
+* Vax-Dependent:: VAX Dependent Features
@end ifset
@end menu
@end ifset
@c end-sanitize-arc
-@ifset VAX
-@include c-vax.texi
-@end ifset
-
@ifset A29K
@include c-a29k.texi
@end ifset
@end ifclear
@end ifset
+@c start-sanitize-d10v
+@ifset D10V
+@include c-d10v.texi
+@end ifset
+@c end-sanitize-d10v
+
@ifset H8/300
@include c-h8300.texi
@end ifset
@include c-hppa.texi
@end ifset
-@ifset SH
-@include c-sh.texi
+@ifset I80386
+@include c-i386.texi
@end ifset
@ifset I960
@include c-m68k.texi
@end ifset
+@ifset MIPS
+@include c-mips.texi
+@end ifset
+
@ifset NS32K
@include c-ns32k.texi
@end ifset
-@ifset SPARC
-@include c-sparc.texi
+@ifset SH
+@include c-sh.texi
@end ifset
-@ifset I80386
-@include c-i386.texi
+@ifset SPARC
+@include c-sparc.texi
@end ifset
@ifset Z8000
@include c-z8k.texi
@end ifset
-@ifset MIPS
-@include c-mips.texi
+@ifset VAX
+@include c-vax.texi
@end ifset
@ifset GENERIC
@raisesections
@end ifset
+@node Reporting Bugs
+@chapter Reporting Bugs
+@cindex bugs in @code{@value{AS}}
+@cindex reporting bugs in @code{@value{AS}}
+
+Your bug reports play an essential role in making @code{@value{AS}} reliable.
+
+Reporting a bug may help you by bringing a solution to your problem, or it may
+not. But in any case the principal function of a bug report is to help the
+entire community by making the next version of @code{@value{AS}} work better.
+Bug reports are your contribution to the maintenance of @code{@value{AS}}.
+
+In order for a bug report to serve its purpose, you must include the
+information that enables us to fix the bug.
+
+@menu
+* Bug Criteria:: Have you found a bug?
+* Bug Reporting:: How to report bugs
+@end menu
+
+@node Bug Criteria
+@section Have you found a bug?
+@cindex bug criteria
+
+If you are not sure whether you have found a bug, here are some guidelines:
+
+@itemize @bullet
+@cindex fatal signal
+@cindex assembler crash
+@cindex crash of assembler
+@item
+If the assembler gets a fatal signal, for any input whatever, that is a
+@code{@value{AS}} bug. Reliable assemblers never crash.
+
+@cindex error on valid input
+@item
+If @code{@value{AS}} produces an error message for valid input, that is a bug.
+
+@cindex invalid input
+@item
+If @code{@value{AS}} does not produce an error message for invalid input, that
+is a bug. However, you should note that your idea of ``invalid input'' might
+be our idea of ``an extension'' or ``support for traditional practice''.
+
+@item
+If you are an experienced user of assemblers, your suggestions for improvement
+of @code{@value{AS}} are welcome in any case.
+@end itemize
+
+@node Bug Reporting
+@section How to report bugs
+@cindex bug reports
+@cindex @code{@value{AS}} bugs, reporting
+
+A number of companies and individuals offer support for @sc{gnu} products. If
+you obtained @code{@value{AS}} from a support organization, we recommend you
+contact that organization first.
+
+You can find contact information for many support companies and
+individuals in the file @file{etc/SERVICE} in the @sc{gnu} Emacs
+distribution.
+
+In any event, we also recommend that you send bug reports for @code{@value{AS}}
+to @samp{bug-gnu-utils@@prep.ai.mit.edu}.
+
+The fundamental principle of reporting bugs usefully is this:
+@strong{report all the facts}. If you are not sure whether to state a
+fact or leave it out, state it!
+
+Often people omit facts because they think they know what causes the problem
+and assume that some details do not matter. Thus, you might assume that the
+name of a symbol you use in an example does not matter. Well, probably it does
+not, but one cannot be sure. Perhaps the bug is a stray memory reference which
+happens to fetch from the location where that name is stored in memory;
+perhaps, if the name were different, the contents of that location would fool
+the assembler into doing the right thing despite the bug. Play it safe and
+give a specific, complete example. That is the easiest thing for you to do,
+and the most helpful.
+
+Keep in mind that the purpose of a bug report is to enable us to fix the bug if
+it is new to us. Therefore, always write your bug reports on the assumption
+that the bug has not been reported previously.
+
+Sometimes people give a few sketchy facts and ask, ``Does this ring a
+bell?'' Those bug reports are useless, and we urge everyone to
+@emph{refuse to respond to them} except to chide the sender to report
+bugs properly.
+
+To enable us to fix the bug, you should include all these things:
+
+@itemize @bullet
+@item
+The version of @code{@value{AS}}. @code{@value{AS}} announces it if you start
+it with the @samp{--version} argument.
+
+Without this, we will not know whether there is any point in looking for
+the bug in the current version of @code{@value{AS}}.
+
+@item
+Any patches you may have applied to the @code{@value{AS}} source.
+
+@item
+The type of machine you are using, and the operating system name and
+version number.
+
+@item
+What compiler (and its version) was used to compile @code{@value{AS}}---e.g.
+``@code{gcc-2.7}''.
+
+@item
+The command arguments you gave the assembler to assemble your example and
+observe the bug. To guarantee you will not omit something important, list them
+all. A copy of the Makefile (or the output from make) is sufficient.
+
+If we were to try to guess the arguments, we would probably guess wrong
+and then we might not encounter the bug.
+
+@item
+A complete input file that will reproduce the bug. If the bug is observed when
+the assembler is invoked via a compiler, send the assembler source, not the
+high level language source. Most compilers will produce the assembler source
+when run with the @samp{-S} option. If you are using @code{@value{GCC}}, use
+the options @samp{-v --save-temps}; this will save the assembler source in a
+file with an extension of @file{.s}, and also show you exactly how
+@code{@value{AS}} is being run.
+
+@item
+A description of what behavior you observe that you believe is
+incorrect. For example, ``It gets a fatal signal.''
+
+Of course, if the bug is that @code{@value{AS}} gets a fatal signal, then we
+will certainly notice it. But if the bug is incorrect output, we might not
+notice unless it is glaringly wrong. You might as well not give us a chance to
+make a mistake.
+
+Even if the problem you experience is a fatal signal, you should still say so
+explicitly. Suppose something strange is going on, such as, your copy of
+@code{@value{AS}} is out of synch, or you have encountered a bug in the C
+library on your system. (This has happened!) Your copy might crash and ours
+would not. If you told us to expect a crash, then when ours fails to crash, we
+would know that the bug was not happening for us. If you had not told us to
+expect a crash, then we would not be able to draw any conclusion from our
+observations.
+
+@item
+If you wish to suggest changes to the @code{@value{AS}} source, send us context
+diffs, as generated by @code{diff} with the @samp{-u}, @samp{-c}, or @samp{-p}
+option. Always send diffs from the old file to the new file. If you even
+discuss something in the @code{@value{AS}} source, refer to it by context, not
+by line number.
+
+The line numbers in our development sources will not match those in your
+sources. Your line numbers would convey no useful information to us.
+@end itemize
+
+Here are some things that are not necessary:
+
+@itemize @bullet
+@item
+A description of the envelope of the bug.
+
+Often people who encounter a bug spend a lot of time investigating
+which changes to the input file will make the bug go away and which
+changes will not affect it.
+
+This is often time consuming and not very useful, because the way we
+will find the bug is by running a single example under the debugger
+with breakpoints, not by pure deduction from a series of examples.
+We recommend that you save your time for something else.
+
+Of course, if you can find a simpler example to report @emph{instead}
+of the original one, that is a convenience for us. Errors in the
+output will be easier to spot, running under the debugger will take
+less time, and so on.
+
+However, simplification is not vital; if you do not want to do this,
+report the bug anyway and send us the entire test case you used.
+
+@item
+A patch for the bug.
+
+A patch for the bug does help us if it is a good one. But do not omit
+the necessary information, such as the test case, on the assumption that
+a patch is all we need. We might see problems with your patch and decide
+to fix the problem another way, or we might not understand it at all.
+
+Sometimes with a program as complicated as @code{@value{AS}} it is very hard to
+construct an example that will make the program follow a certain path through
+the code. If you do not send us the example, we will not be able to construct
+one, so we will not be able to verify that the bug is fixed.
+
+And if we cannot understand what bug you are trying to fix, or why your
+patch should be an improvement, we will not install it. A test case will
+help us to understand.
+
+@item
+A guess about what the bug is or what it depends on.
+
+Such guesses are usually wrong. Even we cannot guess right about such
+things without first using the debugger to find the facts.
+@end itemize
+
@node Acknowledgements
@chapter Acknowledgements
Ian Lance Taylor of Cygnus Support merged the Motorola and MIT syntax for the
68k, completed support for some COFF targets (68k, i386 SVR3, and SCO Unix),
-added support for MIPS ECOFF and ELF targets, and made a few other minor
-patches.
+added support for MIPS ECOFF and ELF targets, wrote the initial RS/6000 and
+PowerPC assembler, and made a few other minor patches.
Steve Chamberlain made @code{@value{AS}} able to generate listings.
Software Foundation (i386 mainly), and Ken Raeburn of Cygnus Support (sparc,
and some initial 64-bit support).
+Richard Henderson rewrote the Alpha assembler.
+
Several engineers at Cygnus Support have also provided many small bug fixes and
configuration enhancements.
projects / deliverable / binutils-gdb.git / blobdiff