Each GAS target specifies two main things: the CPU file and the object format
file. Two main switches in the `configure.in' file handle this. The
first switches on CPU type to set the shell variable cpu_type
. The
second switches on the entire target to set the shell variable fmt
.
The configure script uses the value of cpu_type
to select two files in
the `config' directory: `tc-CPU.c' and `tc-CPU.h'.
The configuration process will create a file named `targ-cpu.h' in the
build directory which includes `tc-CPU.h'.
The configure script also uses the value of fmt
to select two files:
`obj-fmt.c' and `obj-fmt.h'. The configuration process
will create a file named `obj-format.h' in the build directory which
includes `obj-fmt.h'.
You can also set the emulation in the configure script by setting the em
variable. Normally the default value of `generic' is fine. The
configuration process will create a file named `targ-env.h' in the build
directory which includes `te-em.h'.
Porting GAS to a new CPU requires writing the `tc-CPU' files. Porting GAS to a new object file format requires writing the `obj-fmt' files. There is sometimes some interaction between these two files, but it is normally minimal.
The best approach is, of course, to copy existing files. The documentation below assumes that you are looking at existing files to see usage details.
These interfaces have grown over time, and have never been carefully thought out or designed. Nothing about the interfaces described here is cast in stone. It is possible that they will change from one version of the assembler to the next. Also, new macros are added all the time as they are needed.
The CPU backend files are the heart of the assembler. They are the only parts of the assembler which actually know anything about the instruction set of the processor.
You must define a reasonably small list of macros and functions in the CPU backend files. You may define a large number of additional macros in the CPU backend files, not all of which are documented here. You must, of course, define macros in the `.h' file, which is included by every assembler source file. You may define the functions as macros in the `.h' file, or as functions in the `.c' file.
TC_CPU
TC_M68K
. You might have to use this
if it is necessary to add CPU specific code to the object format file.
TARGET_FORMAT
OBJ_FMT
macro.
TARGET_ARCH
bfd_set_arch_mach
.
TARGET_MACH
bfd_set_arch_mach
. If
it is not defined, GAS will use 0.
TARGET_BYTES_BIG_ENDIAN
md_shortopts
md_longopts
md_longopts_size
md_parse_option
md_show_usage
md_shortopts
is a const char *
which GAS adds to the machine
independent string passed to getopt
. md_longopts
is a
struct option []
which GAS adds to the machine independent long options
passed to getopt
; you may use OPTION_MD_BASE
, defined in
`as.h', as the start of a set of long option indices, if necessary.
md_longopts_size
is a size_t
holding the size md_longopts
.
GAS will call md_parse_option
whenever getopt
returns an
unrecognized code, presumably indicating a special code value which appears in
md_longopts
. GAS will call md_show_usage
when a usage message is
printed; it should print a description of the machine specific options.
md_begin
md_cleanup
md_assemble
md_assemble
will do this by calling frag_more
and writing out
some bytes (see section Frags). md_assemble
will call fix_new
to
create fixups as needed (see section Fixups). Targets which need to do special
purpose relaxation will call frag_var
.
md_pseudo_table
pseudo_typeS
. It is a mapping from
pseudo-op names to functions. You should use this table to implement
pseudo-ops which are specific to the CPU.
tc_conditional_pseudoop
pseudo_typeS
argument.
It should return non-zero if the pseudo-op is a conditional which controls
whether code is assembled, such as `.if'. GAS knows about the normal
conditional pseudo-ops,and you should normally not have to define this macro.
comment_chars
const char
array of characters which start a
comment.
tc_comment_chars
comment_chars
.
line_comment_chars
const char
array of characters which start a
comment when they appear at the start of a line.
line_separator_chars
const char
array of characters which separate
lines (the semicolon is such a character by default, and need not be listed in
this array).
EXP_CHARS
const char
array of characters which may be
used as the exponent character in a floating point number. This is normally
"eE"
.
FLT_CHARS
const char
array of characters which may be
used to indicate a floating point constant. A zero followed by one of these
characters is assumed to be followed by a floating point number; thus they
operate the way that 0x
is used to indicate a hexadecimal constant.
Usually this includes `r' and `f'.
LEX_AT
LEX_NAME
and LEX_BEGIN_NAME
,
both defined in `read.h'. LEX_NAME
indicates that the character
may appear in a name. LEX_BEGIN_NAME
indicates that the character may
appear at the beginning of a nem.
LEX_BR
LEX_PCT
LEX_QM
LEX_DOLLAR
LEX_NAME | LEX_BEGIN_NAME
.
SINGLE_QUOTE_STRINGS
NO_STRING_ESCAPES
ONLY_STANDARD_ESCAPES
md_start_line_hook
LABELS_WITHOUT_COLONS
TC_START_LABEL
NO_PSEUDO_DOT
TC_EQUAL_IN_INSN
TC_EOL_IN_INSN
md_parse_name
reg_section
.
md_undefined_symbol
md_begin
is called.
md_operand
input_line_pointer
will point to the start
of the expression.
tc_unrecognized_line
md_do_align
HANDLE_ALIGN
md_flush_pending_output
TC_PARSE_CONS_EXPRESSION
.word
. You can use this to recognize relocation
directives that may appear in such directives.
BITFIELD_CONS_EXPRESSION
REPEAT_CONS_EXPRESSION
md_cons_align
TC_CONS_FIX_NEW
md_number_to_chars
number_to_chars_bigendian
or
number_to_chars_littleendian
, whichever is appropriate. On targets like
the MIPS which support options to change the endianness, which function to call
is a runtime decision. On other targets, md_number_to_chars
can be a
simple macro.
md_reloc_size
BFD_ASSEMBLER
and not MANY_SEGMENTS
). It holds the size of a
relocation entry.
WORKING_DOT_WORD
md_short_jump_size
md_long_jump_size
md_create_short_jump
md_create_long_jump
WORKING_DOT_WORD
is defined, GAS will not do broken word processing
(see section Broken words). Otherwise, you should set md_short_jump_size
to
the size of a short jump (a jump that is just long enough to jump around a long
jmp) and md_long_jump_size
to the size of a long jump (a jump that can
go anywhere in the function), You should define md_create_short_jump
to
create a short jump around a long jump, and define md_create_long_jump
to create a long jump.
md_estimate_size_before_relax
rs_machine_dependent
frag before any relaxing is done. It may also create any necessary
relocations.
md_relax_frag
md_relax_frag
should
return the change in size of the frag. See section Relaxation.
TC_GENERIC_RELAX_TABLE
md_relax_frag
, you may define
TC_GENERIC_RELAX_TABLE
as a table of relax_typeS
structures. The
machine independent code knows how to use such a table to relax PC relative
references. See `tc-m68k.c' for an example. See section Relaxation.
md_prepare_relax_scan
LINKER_RELAXING_SHRINKS_ONLY
md_begin
), a
`.align' directive will cause extra space to be allocated. The linker can
then discard this space when relaxing the section.
md_convert_frag
md_apply_fix
TC_HANDLES_FX_DONE
md_apply_fix
correctly sets the
fx_done
field in the fixup.
tc_gen_reloc
BFD_ASSEMBLER
GAS will call this to generate a reloc. GAS will pass
the resulting reloc to bfd_install_relocation
. This currently works
poorly, as bfd_install_relocation
often does the wrong thing, and
instances of tc_gen_reloc
have been written to work around the problems,
which in turns makes it difficult to fix bfd_install_relocation
.
RELOC_EXPANSION_POSSIBLE
tc_gen_reloc
may return multiple
relocation entries for a single fixup. In this case, the return value of
tc_gen_reloc
is a pointer to a null terminated array.
MAX_RELOC_EXPANSION
RELOC_EXPANSION_POSSIBLE
is defined; it
indicates the largest number of relocs which tc_gen_reloc
may return for
a single fixup.
tc_fix_adjustable
MD_PCREL_FROM_SECTION
md_pcrel_from
MD_PCREL_FROM_SECTION
. The difference is
that md_pcrel_from
does not take a section argument.
tc_frob_label
md_section_align
tc_frob_section
BFD_ASSEMBLER
GAS will call it for each
section at the end of the assembly.
tc_frob_file_before_adjust
tc_frob_symbol
tc_frob_file
tc_frob_file_after_relocs
LISTING_HEADER
"GAS LISTING"
.
LISTING_WORD_SIZE
LISTING_LHS_WIDTH
LISTING_WORD_SIZE
bytes. The
default value is 1.
LISTING_LHS_WIDTH_SECOND
LISTING_LHS_WIDTH
, but applying to the second and subsequent line
of the data printed for a particular source line. The default value is 1.
LISTING_LHS_CONT_LINES
LISTING_RHS_WIDTH
As with the CPU backend, the object format backend must define a few things, and may define some other things. The interface to the object format backend is generally simpler; most of the support for an object file format consists of defining a number of pseudo-ops.
The object format `.h' file must include `targ-cpu.h'.
This section will only define the BFD_ASSEMBLER
version of GAS. It is
impossible to support a new object file format using any other version anyhow,
as the original GAS version only supports a.out, and the MANY_SEGMENTS
GAS version only supports COFF.
OBJ_format
OBJ_ELF
. You might have to use this
if it is necessary to add object file format specific code to the CPU file.
obj_begin
obj_app_file
.file
pseudo-op or a `#' line as used by the C preprocessor.
OBJ_COPY_SYMBOL_ATTRIBUTES
obj_fix_adjustable
obj_sec_sym_ok_for_reloc
EMIT_SECTION_SYMBOLS
obj_adjust_symtab
.file
symbol if none was generated previously.
SEPARATE_STAB_SECTIONS
INIT_STAB_SECTION
OBJ_PROCESS_STAB
obj_frob_section
obj_frob_file_before_adjust
obj_frob_symbol
obj_frob_file
obj_frob_file_after_relocs
Normally you do not have to write an emulation file. You can just use `te-generic.h'.
If you do write your own emulation file, it must include `obj-format.h'.
An emulation file will often define TE_EM
; this may then be used
in other files to change the output.
Go to the first, previous, next, last section, table of contents.